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editor. This real-time prototype executes on two processors using a client/server 
architecture; the user interface executes on a client, and the real-time PSDL application 
executes on a server. In addition, this thesis includes demonstrations, with source code, 
which implement the design. The demonstrations show that Java development tools can 
be used to create a high-quality user interface for a PSDL application. A socket 
connection was used to implement the client/server communication. The demonstrations 
were successful, but the socket programming model is too primitive for the new design. 
Therefore, a high-level client/server architecture, such as the Common Object Resource 
Broker Architecture (CORBA), is required for future development of the design. 
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I. INTRODUCTION 



A. GENERAL 

In the development of software applications, the user interface software is often 
complex, large, and difficult to design. The user interface is the aspect of a computer 
program that has the most direct contact with the user. Likewise, the design of user 
interfaces has become an important part of the Computer-Aided Prototyping System 
(CAPS). CAPS is a collection of engineering tools, which are used to design real-time 
systems. A CAPS user enters specifications using the Prototyping System Description 
Language (PSDL). To complete the prototype, the user designs a user interface with the 
CAPS interface editor. Finally, the PSDL is translated into Ada; the Ada is linked with 
the user interface; and the prototype application is executed. 

CAPS is an evolving research project, and many of its components are still under 
development. The user interface development tools of CAPS need to be revised. For 
instance, the current version of CAPS is only fully functional on a Sun Microsystems 
workstation running SunOS UNIX. Currently, the CAPS interface editor is Century 
Computing’s Transportable Applications Environment (TAE). TAE is only available for a 
few platforms, and it has limited capabilities. In addition, the CAPS user interface, written 
in Motif, is not easily ported to other platforms. 

B. PROBLEM STATEMENT 

A CAPS designer uses the prototyping process to create an application. PSDL is 
used to express the specifications of the application. Next, the CAPS interface editor can 
be used to create a prototype user interface. Unfortunately, the current interface editor does 
have the support and functionality that is required. This thesis focuses on creating a new 
design for linking a user interface with a PSDL application. In addition, this thesis 
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evaluates user interface development tools, which could be used to increase the 
functionality, portability, and versatility of CAPS. 

C. SCOPE 

The scope of this work was originally intended to integrate a commercial user 
interface development tool into CAPS. As work on this thesis progressed, it became clear 
that a new design for linking the user interface with the prototype was required. This 
design is based upon a client/server architecture. In addition, two demonstrations that use 
the new design are included. 

D. ORGANIZATION OF THESIS 



Chapter II contains background information about CAPS, user interface 
development tools, and supporting documentation. Chapter III presents the design process 
and results. Chapter IV presents the implementation of the new design. Chapter V 
contains demonstrations of the new design. Chapter VI provides the conclusion and a 
discussion of future research. Appendix A contains evaluations of user interface 
development tools. 



2 



II. BACKGROUND 



A. COMPUTER-AIDED PROTOTYPING SYSTEM 



The Computer-Aided Prototyping System (CAPS) is a software engineering tool 
for developing prototypes of real-time systems [Ref 1]. CAPS was designed to allow a 
user to build software specifications and make them executable. In addition, CAPS can be 
used for requirements analysis, evaluation of models, and designing large-embedded 
systems. CAPS promotes the rapid prototyping life cycle (Figure 1). Rapid prototyping 
is an alternative paradigm for software development. By using the prototyping process, a 
user can validate system requirements early in the project’s life cycle. In addition, CAPS 
includes tools for software reuse and evolution. [Ref 2] 




Figure 1. The Rapid Prototyping Life Cycle “From Ref [7]” 



A CAPS user specifies relationships, data flow, and constraints between 
software objects. These specifications are expressed in the Prototyping System 
Description Language (PSDL). The user initially works at a high level of abstraction, 
breaking down the objects into lower levels of abstraction. At the lowest levels, existing 
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code from a software library is used to implement the object. Alternatively, a high-level 
language, such as Ada, can be used to implement the object. The papers [Ref. 3], [Ref 4], 
[Ref 5], [Ref 6], and [Ref 7] provide more information about CAPS. 

1. CAPS Components 

CAPS is a development environment consisting of tools linked by a user interface 
(Figure 2). The main sections of CAPS include.- editors, execution support, software 
database, and project control. The editors are used to implement the software design. 
Execution support is for software translation, real-time scheduling, and compilation. The 
software database is intended for software storage and reuse. Project control contains 
tools for software evolution, such as revision control, merging of software versions, and 
project planning. [Ref 8] 

2. Prototyping System Description Language 

A CAPS user can input software specifications via the Prototyping System 
Description Language (PSDL). PSDL is a text-based language designed to express 
specifications of real-time systems. PSDL has only two kinds of components: operators 
and types. PSDL is based on a graph model of edges and vertices (Figure 3). The edges 
represent streams of data flow from one operator to another. The streams arc instances of 
types. The vertices represent software operators. The operators can either be sporadic or 
periodic. The operators may have associated timing constraints. An example timing 
constraint is Maximum Execution Time (MET). In PSDL, the MET of an operator must 
not be exceeded, otherwise a timing error will be displayed. In addition, the operators may 
also have control constraints. Control constraints for a periodic operator include: Finish 
Within (FW) and Period. [Ref 3] 

PSDL supports the concept of program abstraction. The PSDL operators can either 
be composite or atomic. An atomic operator is implemented in a standard programming 
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language such as Ada. A composite operator can be decomposed into a sub-layer 
containing operators and streams. [Ref. 3] 




Figure 2. CAPS and Graph Editor 
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3. Monitoring PSDL Execution 

By using PSDL, a CAPS user can create a prototype application. In most cases, a 
CAPS user must be able to monitor the prototype’s execution. Even if the prototype is 
destined to be an embedded application without a Graphical User Interface (GUI), the user 
may require a GUI to evaluate the prototype. Alternatively, a user may also require a GUI 
to emulate an external environment. 

CAPS has built-in diagnostics, which monitor a prototype’s execution. 
Additionally. CAPS monitors the execution times of the operators. The user will be 
notified if timing constraints are violated. CAPS prints data-stream errors and exceptions 
during the execution of the prototype. 

In addition to diagnostic output, a CAPS user may wish to observe data values, 
provide input, and observe simulations. A user can add simple print statements to monitor 
execution of a PSDL application. This is traditionally done by adding Ada print 
statements to the atomic operator’s implementation. 

4. Interface Editor 

The interface editor is a GUI development tool designed to help the developer 
create high-quality user interfaces in a short period of time. If a CAPS user requires more 
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than just simple print statements in the prototype application, he/she can use the CAPS 
interface editor to design a graphical user interface prototype {GUI-prototype). The GUl- 
prototype allows a user to display and input information in a window-based environment. 
In many real-time embedded applications, the GUI-prototype is only required for analysis. 
In most cases, the GUI-prototype does not have timing constraints. It is important that the 
GUI-prototype not interfere with the real-time execution of the prototype application. 
[Ref. 8][Ref 9] 

5. CAPS Release 1.1 Interface Editor: TAE 

CAPS Version l.I currently incorporates Century Computing’s TAE as the 
interface editor [Ref 8][Ref 10]. TAE allows a user to quickly create X-Widows/Motif 
based GUl-prototypes. TAE generates C or Ada program code. To create a prototype 
application, the TAE-Ada code is linked with translated PSDL. 

TAE has some very useful features, including a GUI builder. In addition, the TAE 
resource file allows widgets to be interchanged without recompiling the entire application. 
Also, TAE allows the building of high-level reusable components. TAE has been 
successfully integrated, documented, tested, and demonstrated with the CAPS system. 

However. TAE has drawbacks with respect to CAPS. TAE is expensive to 
support, license, and to include in the release of CAPS. In addition, TAE is not platform 
independent. Also, TAE does not work with all versions of UNIX. Most importantly, the 
current integration of TAE alters the TAE event manager. TAE is linked with a prototype 
application by removing the infinite loop from the TAE event manager. As a result, the 
protot>pe application is responsible for polling the TAE widgets. This design can make 
the prototype application sluggish to user input and slow when displaying data. 

For information on how to link in TAE and PSDL consult [Ref 8]. For 
information on how to use TAE, consult [Ref 10]. 
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B. GUI DEVELOPMENT TOOLS 



Graphical User Interface (GUI) design is a field in computer science that has been 
changing rapidly in the last ten years. Window-based operating systems have allowed 
applications to have sophisticated user interfaces. Unfortunately, user interface software is 
often complex, large, and difficult to program. Traditionally, programmers have used 
toolkits to develop GUIs. The toolkits use the functionality of the platform’s windowing 
and operating system. Fortunately, new software development tools are now available to 
aid the software designer. A GUI development tool is defined as software to aid in the 
creation of graphical user interfaces. Most GUI development tools are based on toolkits to 
achieve their look-and-feel. A few development tools do not make direct calls to the 
standard toolkits, but emulate the look-and-feel of the toolkits. Figure 4 shows the 
layering of GUI software. 

Application 

GUI Development Tools 
GUI Toolkits 
Windowing System 
Operating System 

Figure 4. Components of GUI Software “After Ref [11]” 

TTie software designer must decide whether to use a GUI development tool or 
program manually with just the toolkit libraries. The decision to program with GUI 
development tools is better than manual coding in several ways. For instance, most tools 
support prototyping, reuse, and code consistency. In contrast, the drawbacks of tools 
could include: added complexity, a higher learning curve, added expense, and performance 
penalties. [Ref 12] 

Object oriented design and coding has become a fundamental part of most GUI 
development tools. Most GUI development tools incorporate abstraction and 
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encapsulation in their design. For example, a software developer may not care to 
understand the inner functionality of a widget, but he/she may just need to know the 
available methods for the widget. 

The GUI development tools can be grouped by the languages supported. 
Alternatively, the tools can also be grouped by the platforms supported. The following 
paragraphs divide the tools based on functionality. However, many of the commercial 
tools do not fit into just one category. [Ref. 12] 

1. GUI Toolkits 

A GUI toolkit is a library of widgets that can be used to develop user interfaces. 
Typical widgets include: buttons, sliders, text-fields, and canvases. Some toolkits contain 
high-level widgets, such as pop-up dialog boxes, which aid the developer in creating 
common interfaces. The use of high-level widgets maintains a consistent look-and-feel 
across different applications. Motif and OpenLook are examples of X-Windows toolkits. 
An example of a platform independent toolkit is Artificial Intelligence Applications 
Institute’s wx Windows [Ref 13]. It is a free-of-charge library for C++. 

2. GUI Builders 

Usually a GUI development product contains a GUI builder to construct and edit 
the interface. Most GUI builders allow the designer to quickly create an interface in a 
Wltai You See Is IVhai You Gel (WYSIWYG) mode. A GUI builder allows the user to 
easily add, delete, and replace widgets. In many cases, a GUI builder can be used by a 
person with little programming experience. In the prototyping process, the ability to 
create GUIs in a short period of time is very important. The GUI builders available today 
vary in quality, ease of use, and training required. 
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3. 



User Interface Management Systems 



A User Interface Management System (UIMS) adds functionality to the GUI, 
without the user having to program in a high-level language. To achieve this 
functionality, some UIMS include high-level scripting languages, which add behavior to 
the GUI. [Ref 14]. Open Software Associates’ OpenUI [Ref 15] and Aonix’s Teleuse 
[Ref 16] are examples of UIMSs. 

4. Analysis, Plotting, Graphics, and Visualization 

Some GUI tools contain graphics and 2D-3D visualization tools. Other tools may 
allow the user to analyze and plot technical data in generic formats. Visual Numerics PV- 
WAVE [Ref 17] and Mathworks’ Matlab [Ref 18] are examples. Some tools support 
real-time analysis of data. DataViews Corporation’s DataViews is an example of this kind 
of tool [Ref 19], 

5. Application Development Environments 

Application development envirorunents contain a wide range of tools, in addition 
to the GUI tools. These products contain tools to aid in the full range of software 
development. These tools could include: group-ware, code-analysis, debugging, evolution 
control, and real-time control. Visix’s Galaxy [Ref 20] and Sun Microsystem’s Visual 
Workshop [Ref 21] are examples of application development environments. 

6. Platform Independent Graphical User Interface 

A Platform Independent Graphical User Interface (PIGUI) is defined as a software 
library that supports at least two different operating systems. [Ref 22] A PIGUI allows a 
developer to create one version of code that runs on multiple platforms. A PIGUI will 
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hopefully decrease the amount of total development time for a project supporting multiple 
platforms. The PI GUI can either preserve the native look-and-feel of the target platform 
or maintain a consistent look-and-feel across platforms. 

There are two types of PIGUIs. The PIGUI can link to the windowing toolkit on 
the target machine. XVT Softwares’s XVT is an example of this kind of PIGUI. [Ref 23] 
Secondly, a PIGUI can re-implement the widgets for each target platform. Visix’s Galaxy 
is an example of this type. [Ref 20] The extra overhead of PIGUIs will generally slow 
down the execution of the application. The supported languages for PIGUIs include C, 
C++, Ada, Java, and others, but the most predominate is C++. [Ref 22] 

C. DE-COUPLING OF THE GUI 

GUI complexity has increased rapidly in the last few years. Users are requiring 
well-planned and sophisticated GUIs. The computer applications of the 1960’s and 1970’s 
had simple user interfaces with very little operator involvement. These early computer 
programs were mostly one-tier applications. A tier is a component of an application that 
is bound through external interfaces to other modules of the application [Ref 24]. One- 
tier applications include all the functionality in one program. This functionality can 
include; presentation management, program rules code, and database access (Figure 5). 
One-tier applications have the advantage of being easy to design, setup, and maintain. On 
the other hand, one-tier applications are not easily scaleable and have inadequate 
performance at high volume. [Ref 25] 




Application 





Presentation management 
Program rules code 
Database access 




Figures. One Tier Application 
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The recent development of client/server middleware and Database Management 
Systems (DBMSs) allowed the developer to separate the database code from the rest of the 
application. Usually, client/server computing involves two or more computers distributing 
tasks appropriate to each computer to complete the application. Client/Server computing 
has been widely used in database systems. Figure 6 shows a DMBS task communicating 
with a database. The DBMS is de-coupled from the rest of the application. [Ref 15] 




Figure 6. Two-tier Client/Server Application 



The separation of the GUI from the application code has mirrored the de-coupling 
of DBMSs [Ref 1 5]. In recent years, the GUI has become the most complex part of many 
applications. A 1992 study found that an average of 48% of an application code is 
devoted to the user interface, and about 50% of the implementation time is devoted to the 
user interface [Ref 12]. In many software designs the GUI is de-coupled from the rest of 
the application. Figure 7 shows a three-tier application; the GUI controls the display, 
handles user input, and requests services from other tiers of the application. 

Multiple-tiered computing has also distributed the tasks of an application to many 
remote sites. Distributed applications use client/server protocols to allow the client 
application to communicate with a server computer system. Distributed computing makes 
the sharing of data and processor resources possible. 
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Client/server computing has advantages and disadvantages. By separating an 
application into multiple tiers and incorporating the client/server model, it is modularized; 
reuse is promoted; and the computing load is distributed [Ref. 24]. Even if a client/server 
application is run on one CPU, it retains the benefits of modularity and reuse. On the 
other hand, a disadvantage of client/server computing is communication complexity. The 
communication protocols can add CPU load to the design. Also, client/server systems are 
harder to setup and design. [Ref 26] 




Figure 7. Three-Tier Software Design: Separation of GUI and DBMS 



D. EVALUATION OF GUI TOOLS 



The number of commercial and public GUI development tools is large and is 
growing rapidly. The GUI tools vary in complexity, price, quality, programming language 
support, platform support, and adherence to standards. The following issues were 
considered in the evaluation of GUI development tools: 

• Type of Tool: toolkit, GUI builder, UlMS, development environment, ... 

• Toolkits supported: Openlook, Motif Java, ... 

• Platform independence 

• Platform support 
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• Operating system support 

• Cost: initial purchase, maintenance 

• Level of vendor support 

• Future support of tools 

• Language Support - Ada, C, C++, Java, 

• GUI builder availability 

• Compliance to standards 

• CAPS integration complexity 

• Ease of use, learning curve 

• Ease of installation 

• Documentation 

• Complexity 

• Prototyping features 

• Visualization tools 

• Plotting and graphics 

• Additional tools: maketool, evolution control, debugging, group-ware, 

Appendix A contains evaluations of GUI development tools and toolkits. 
Additional information about these and other tools can be found in the papers [Ref. 22] 
and [Ref. 25]. 
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III. DESIGN OF A CAPS INTERFACE EDITOR 



A. DESIGN PROCESS 



As mentioned in the introduction, this thesis focuses on the development of a new 
interface editor for CAPS. The first step is determining the purpose of the work. The next 
step is to evaluate the current CAPS’ programming environment and determine the 
assumptions, goals, and constraints for a new design. Since CAPS is a group effort, this 
thesis must maintain consistency with the previously developed applications. 



1. Purpose 

The purpose of the CAPS interface editor is to allow a CAPS user to create a GUI- 
prototype for a prototype application. In addition, the GUI development tools could be 
used to port the CAPS tools, such as Graph Editor (GE), to other platforms. 



2. Assumptions 

1 . The CAPS user will be familiar with the capabilities of the 
hardware/software platform. 

2. The CAPS user will have knowledge of computer window systems. 

3. The CAPS user will be familiar with CAPS, PSDL, and the chosen 
programming language. 

3. Goals/Constraints 



1 . Goals for an Interface Editor 

1.1 The interface editor must integrate into the existing version of CAPS. 

1 .2 The interface editor must run on a variety of platforms and operating 
systems besides SunOS UNIX. 

1 .3 The GUI tools’ licensing costs should be kept to a minimum. 

1 .4 The execution of a CAPS prototype should not be adversely effected by 
the GUI repaint and input events. 
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1.5 The interface editor must be easy to use and be intuitive to a new user. 

1 .6 The interface editor should contain a variety of high-level widgets to 
aid in the development of user interfaces. 

1 .7 The interface editor should contain a GUI builder tool. 

1.6.1 Using the GUI builder, the interface widgets can be added, 
deleted, and replaced. 

1.6.2 The GUI builder should be able to create high-level widgets. 

1.7 The interface editor should require little training. 

1.8 The interface editor should be easy to use. 

1 .9 The GUI-prototype may or may not be part of the static schedule. 



2. Constraints 

2.1 The GUI integration will be incorporated into CAPS Version 1.1. 

2.2 The GUI integration will be developed on a Sun Microsystems Sparc- 
10 running SunOS 4.1.4. 



B. DESIGN RESULTS - GUI-CLIENT / PSDL-SERVER 

When using CAPS, the GUI-prototype is for analysis of design, displaying data, 
and user interaction with the PSDL application. Alternatively, a CAPS designer may want 
the GUI-prototype to emulate an external environment. The GUI-prototype may not have 
real-time constraints or be required in a final embedded system, but it will require CPU 
resources. In this case, it is important that the GUI-prototype not interfere with the real- 
time execution of prototype application. 

As a result, the new design de-couples the GUI-prototype from the rest of the 
prototype. The new design contains components from a multi-tier client/server 
architecture. The new design creates a GUI-client that communicates with a PSDL-serwr. 
A GUI-client is defined as a GUI-prototype, which is de-coupled from the PSDL and 
executes on a client processor. A PSDL-server is a PSDL application, without a GUI, 
which executes on a server processor. With this design, a user can create the GUI-client 
with any programming language and GUI development tools. The client/server 
architecture allows the GUI-client to be located on a local CPU, while the PSDL-server is 
running on a remote CPU (Figure 8). The GUI-client event model can be retained by 
rurming the PSDL-server on a different CPU. Also, the real-time schedule of the PSDL- 
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server is not affected by the GUI-client. In addition, the design allows the GUI-client to 
be compatible with existing CAPS Version 1.1 software. 

The client/server communication is possible with a variety of middleware 
solutions. The simplest middleware solution is sockets. 




Figure 8. Multiple CPUs CAPS Client/Server 



Alternatively, the client/server design could be implemented on one CPU if the 
processing of the GUI-client is taken into account. For this purpose, a prototype 
application could be run on one CPU by using synchronous communications between the 
GUl-clicnt and the PSDL-server as shown in Figure 9. As a result, the synchronous 
communications could prevent the GUI-client from taking CPU resources during the 
execution of the PSDL-server. 

Threads could be used to implement the one-CPU design. The first thread could 
execute the PSDL-server, while the second thread handles the GUI-client during non- 
critical times. Also, a single workstation with multiple CPUs could be evaluated. 

Problems with the client/server design include: increased overhead and network 
traffic. A dedicated network will minimize the amount of network traffic. Another 
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problem with a CAPS client/server design is the added complexity in the overall CAPS 
system. 



Single CPU 





Figure 9. One CPU CAPS Client/Server 
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IV. IMPLEMENTATION CONSIDERATIONS 



A. SELECTION OF GUI TOOLS 

I spent approximately six months evaluating and selecting GUI development tools. 
There are over a hundred commercial tools available. In addition, many universities have 
departments that are doing GUI research, and they offer their GUI development tools free- 
of-charge. Appendix A describes the evaluated tools. The following tools are considered 
as possible choices for integration in CAPS. 

1. Fresco 

Fresco is an object-oriented development toolkit for the development of user 
interfaces[Ref. 27]. Fresco is a design evolution from Stanford University’s Interviews 
toolkit. Fresco was developed at Fujitsu’s Faslab in conjunction with the X-Consortium. 
The Opengroup’s X-Windowsl 1-V6 (Broadway) contains a sample implementation of 
Fresco. [ Ref 28] 

Unfortunately, Faslab discontinued support and development work on Fresco in 
late 1996. Also, the software community has failed to widely use Fresco. For these 
reasons Fresco was not integrated into CAPS. 

2. Java Development Kit 

The Java programming language, developed by Sun Microsystems, is being hyped 
as a replacement for C and C-H-. The Java programming language is becoming the 
programming language of choice for many internet and standalone applications [Ref 
29][Ref 30]. Java is not a GUI development tool, but only a language and toolkit. 
Fortunately, many vendors are now selling complete GUI development environments for 
Java. Additionally, many traditional Motif development tools are now supporting Java. 
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Java is an object-oriented, distributed, interpreted, secure, platform-independent, 
and multithreaded programming language. Unlike most languages, Java has automatic 
garbage collection. Java has client/server protocols included in the language’s API. In 
addition, Java has a built-in Abstract Window Toolkit (AWT). The AWT can be 
considered a PIGUI because it runs on mulitple platforms without program modification. 
The Java AWT also supports the native look-and-feel of the target platform. 

Consequently, many universities are now offering Java as the introductory 
programming language instead of C++. Appendix A contains more information about the 
Java programming language and development tools. 

A GUI-client written in Java would allow the interface to run on almost zmy 
platform and communicate with a PSDL-server. Java was selected to test integration with 
CAPS. 



3. Visual Workshop / X-Designer 

Sun Microsystems’ Visual Workshop and Imperial Software Technology’s (1ST) 
X-Dcsigner arc X- Windows/Motif tools for UNIX platforms. Visual Workshop 
incorporates IST’s GUI builder (X-Designer) into its product. Both tools provide about 
the same functionality. The tools create Motif X-Windows code written in C and C++. 
Ada95 can be generated with OC-Systems’ XDA attachment. Visual Workshop was also 
selected to test integration with CAPS. [Ref 21][Ref 31] 

B. SELECTION OF CLIENT/SERVER MIDDLEWARE 

The number of techniques for implementing client/server middleware is very large. 
Many vendors are trying to sell their products and create standards. The products include: 
Sockets. CORBA, CGI, Netscape’s Caffeine, Java-RMI, and Microsoft’s DCOM. 
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1 . 



Sockets 



A socket is the basic protocol for client/server communication over TCP/IP stacks. 
Sockets were originally introduced in 1981 for UNIX BSD 4.2. Sockets are available on 
almost every operating system. Sockets are available in several forms: datagram, stream, 
and raw. The most common socket API is the Berkley UNIX C protocol. Sockets can 
also be used for communication on a single computer. Figure 10 shows a typical sequence 
for establishing a client/server connection. Sockets are the basis for most higher level 
client/server middleware. The socket programming model is quite primitive, but it is very 
fast and a well-known standard. Sockets were implemented and evaluated as a possible 
middleware between the PSDL-server and the GUI-client. [Ref 32][Ref 33] 



^ Server 

socketQ 

bindO 

listenQ 

' acceptO /* wait for request */ ' 



Begin thread 



Loop for next request 



i 

recvfromO 

sendQ 

cIoseQ 



socketQ 

connectQ 


Client 


sendtoQ 


/* write data *1 


recvfromO 

closeQ 


/* read data *1 



Figure 10. Client/Server Scenario 



2. Common Object Request Broker Architecture (CORBA) 



CORBA is a middleware project being developed by the Object Management 
Group (0MB) consortium, consisting of over 700 companies. The notable exception to 
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this group of companies is Microsoft, which has a competing product called the 
Distributed Component Object Model (DCOM). CORE A could replace all other 
implementations of client/server middleware. In CORBA client/server computing, objects 
cooperate over the network as opposed to cooperating processes. [Ref 32] Specifications 
for CORBA objects are written with the Interface Definition Language (IDL). IDL 
provides operating system and programming language interfaces to other services on the 
CORBA bus. CORBA allows almost any programming language to communicate over a 
network as show in Figure 1 1 . 



Cp© 


^Ad^ 1 


Cp© 




1 IDL 1 1 IDL 1 1 IDL 1 1 LDL 1 | 


1 IDL 1 1 IDL 1 1 IDL 1 1 IDL | 










Cbent 




Server 











Object Resource Broker (ORB) 



Figure 1 1 . CORBA 



C. PSDL-SERVER - SOCKET - GUI-CLIENT 

In this implementation, A GUI-client, written in Java or Motif, communicates with 
a PSDL-server by using TCP/IP sockets. Figure 12 shows the implementation of the 
design. Demonstrations of the implementation are described in the next chapter. The 
source code for the demonstrations is in Appendix B. 

The PSDL Ada atomic operators bind to a C module that implements the server 
side of the socket connection. The server socket is written is C because of the difficulty in 
implementing sockets with the VADS Ada83 compiler. 
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A protocol is established for passing a data structure between the GUI-client and 
the PSDL-server. An example communication data structure is shown below: 

struct CapsData { 

char command_number; 
int il 
int i2; 

char buffer[SIZE]; 

} 

At present, the communications data structure is modified for each new 
application. A more generic data structure should be designed to work with all prototype 
applications. The client/server communications in the demonstrations are synchronous. 
Asynchronous communication may also be used, but care must be taken to avoid data-loss 
or deadlocks. The implementations are multithreaded. One thread in the GUI-client is 
devoted to the socket communication. 




Figure 12. CAPS-Socket-GUI 
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1 . 



Java GUI-client 



The GUI-client was implemented using the Java programming language. The Java 
GUI-client can be created with the Java development kit or designed with development 
tools, such as Symantec’s Visual Cafe [Ref. 34]. The Java GUI-client can either be a 
standalone application or run as an applet in a network browser. The Java implementation 
is multithreaded. Unfortunately, programming Java threads can be difficult. The Thread 
Scheduling Model, which is platform dependent, determines the thread that will be running 
at any given time. Some operating systems use preemptive scheduling and others use time 
slicing. Consequently, the programmer must carefully design the application so that it is 
still platform independent. The code for a Java implementation is in Appendix B. 

2. Motif GUI-client 

Another GUI-client was implemented in Motif using Visual Workshop (Version 
3.) for a Sun Microsystems’ workstation. The GUI-client is also multithreaded. The code 
for a Motif implementation is included in Appendix B. 



D. PSDL-SERVER - CORBA - GUI-CLIENT 

CORBA has the potential of making middleware transparent to the application 
programmer. In this thesis, the CORBA middleware was not fully implemented. A 
CORBA interface is written in IDL. An example IDL interface between the PSDL-server 
and the GUI-client is as follows; 



//IDL 

interface Capsdata [ 
attribute int ix; 
attribute int iy 
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int repaintO 
int readdataQ 
int writedataO; 
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V. DEMONSTRATIONS OF NEW DESIGN 



A. ROBOT CONTROL SYSTEM 

This demonstration reworks a CAPS project originally developed in CS4920 
(Spring 1996). The project developed a software prototype for a robot control system. 
The prototype was developed using CAPS Version 1.1. This demonstration uses a socket 
to connect the GUI-client with the PSDL-server. 

1. Requirements for Robot Control System 

The robot moves on a friction-less table using air bearings, and is equipped four 
compressed air thrusters that are aligned with the directions of the coordinate axes (+x, -x, 
■•■y* -y)- Opposing thrusters should never be both turned on at the same time. Thruster 
force can be continuously varied under computer control. The maximum thrust from each 
thruster produces an acceleration of 1 meter per second per second. The software is 
supposed to provide a “soft landing” capability for the robot. In the test bench for the robot 
control software, the initial positions (x and y coordinates of the robot) and initial 
velocities (x and y components of its speed) are specified as input. The controller is 
supposed to bring the robot to a stop at a position less than 2 cm from the origin of 
coordinate system. The robot must never get closer than 1 cm from the origin, and it must 
stay within the border of the table ( -1 meter <= x <= 1 meter and -1 meter <= y <= 1 
meter). The initial position must be a legal position, and both components of the initial 
velocity must not exceed 1 meter per second. 

2. Robot: PSDL-server 

CAPS (Version 1.1), running on a Sun Microsystems’ Sparc 10 (SUNOS 4.14), 
was used to implement the demonstration. The PSDL for this demonstration is simple, but 
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contains time-critical operations. Appendix B contains the source code for the PSDL- 
server. Figure 13 shows the Robot PSDL graph. The operators bopjdisplay and 
bopjlnput are atomic operators implemented in Ada. These operators bind to a C program 
that implements the server connection. The atomic operator bopjdisplay sends data to 
GUl-client while bopjnput requests input from the GUI-client. 




Figure 13. Robot PSDL Graph 



Code fragments for the PSDL-server are shown below. The file ada.h contains the 
data structure that is passed between the GUI-client and PSDL-server. TTie file 
“bop_display.a” is source code for the atomic operator bop_display. This atomic operator 
passes display data to GUI-client. Inside “bop_display.a”, the function call socket( ) 
passes the data structure to the GUI-client. The file “socket. a” contains the source code 
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for socket( ), which binds to the C program “server.c” which performs the actual socket 
connection, socket binding, and data transfer. 



- FILE : ada.h 



typedef struct { 

int ix; 

int iy; 

int ir; 

} Rec, *Rec_Ptr; 



— FILE : socket.a 



-pkg 

package body socket PKG is 
al : FLOAT; 
bl : FLOAT; 
type Rec is record 

ix: Integer ; 
iy: Integer ; 
ir: Integer ; 
end record; 

type Rec_Ptr is access Rec; 

I : Rec_Ptr := new Rec; 
pragma LINK_WITH fserver.o"); 
procedure server(I : in Rec_Ptr); 
pragma Interface (C, server ); 

procedure Socket(xx: in out Float; yy: in out Float; 
ireq: m out INTEGER) is 

begin 



server(I); 



end Socket; 
end socket PKG; 



-FILE : bop display.a 



with pva data Pkg; 
with socket Pkg; 
use socket Pkg; 

procedure bop_display(bnss_pva_data: in pva_data_Pkg.pva_data) is 
begin 
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socket(fx,fy,ix); 



— Send the x,y position to the GUI-client. 



end bopdisplay; 

3. Robot: GUI-Client 

The GUI-client can be written with almost any language and GUI development 
tools. A GUI-client communicates with the PSDL-server. 

a. Java 

The Java GUI-client was developed on a Sun Microsystems’ UltraSparc 
(Solaris 2.5) and a Windows95 PC, using the Java Developers Kit (Version 1.1). In 
addition, Symantec’s Visual Cafe (Version 1.0) was used to develop the GUI-client. The 
Java program can be designed for a browser or as a standalone application. Figure 14 
shows a Java-applet version of the GUI-client. The source code for the applet version is in 
Appendix B. The Java applet is being displayed in a Netscape browser. The Java program 
is multithreaded. One thread responds to read/write data via the socket, while the other 
thread waits for user input and paints the screen. 

The Java program has various controls. The “Restart” button reinitializes 
the socket connection. The “Zoom” button changes the aspect of the view. The user can 
enter the initial x, y, x-velocity, y-velocity. The user can also drag the robot to a new 
starting location. 

b. V’isual Workshop 

The GUI-client was also implemented using Sun Microsystems’ Visual 
Workshop version 3.0. running on a Sun Microsystems’ Sparcstation-20 (Solaris 2.5). 
The GUI-client is very simple, but it does contain a thread to read/write data from the 
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PSDL-server. Figure 15 shows the Visual Workshop GUI builder, with the GUI-client 
loaded. Figure 16 shows the Visual Workshop version of the GUI-client. 



^ £j Netscape: CAPS Robot Lander Craft - Client/Server JAVA JDK 



'-;5Tr^'d: _ ■ - - . - . . " ; : ' 

File Edit View ' Go Bookmarke Opiione Directory Window .V : Help 







Figure 14. Java GUI-Client 
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Figure 16. Visual Workshop GUl-Clicnt 
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B. SMARTSHIP PROJECT 



The Smartship Project commenced in December 1995 in response to the CNO’s 
review of the 1995 Summer NRAC study which focused on reduced manning. The study 
concluded that major reductions in maiming could be achieved by design in new 
construction ships. Commander Naval Sea Systems Command responded to the CNO’s 
desire to focus on existing operational ships. The overall goal is to reduce workload, 
improve mission readiness, and maintain safety at minimum cost to the government. A 
Naval Postgraduate School thesis “Smartship Project Modeling”, by Nolan Ruiz, is trying 
to determine if an effective modeling approach for the Smartship project can be found. In 
addition, it tries to determine if the current Productivity Allowance is valid. [Ref. 35] 

This thesis will look at possible user interfaces, using the GUI-client/PSDL-server 
design, that could be used with the Smartship project. A socket is usedto connect the 
GUI-client with the PSDL-server. This demonstration will contain only preliminary 
results, but Nolan Ruiz’s thesis will contain a complete prototype. 



1. Smartship PSDL-server 

The ManpowerAVorkload profile of a ship’s Communications Division was 
evaluated. Tasks can either be periodic or sporadic. Periodic tasks include: Station 
Watch, PMS Actions, and Field Day. Sporadic tasks include: Underway Replenishment, 
Vertical Replenishment, General Quarters Drills, Fire Drills, Security Drills and Training. 

CAPS (Version 1.1), running on a Sun Microsystems’ SparclO (SUNOS 4.14), 
was used to implement the CAPS demonstration. The top-level PSDL graph contains the 
following composite operators: SHIP, NAVSEA, and USER. The SHIP composite 
operator can be broken down into periodic and sporadic tasks. Figure 17 is the PSDL 
graph for the SHIP composite operator. The data flow between the operators (the periodic 
and sporadic tasks) is in man-hours. 
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Figure 17. Smartship PSDL 



2 , Smartship GUI-client 

The Java GUI-client was developed on a Sun Microsystems’ UltraSparc (Solaris 
2.5) and a Windows95 PC, using the Java Developers Kit (Version 1.1). In addition, 
Symantec’s Visual Cafe (Version 1.0) was used to develop was used to develop the GUI- 
client. Figure 18 is a Java version of a GUI-client for the Smartship prototype. 
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Figure 18 . Smaitship GUl-client (Java) 
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VI. CONCLUSION 



A. SUMMARY OF DESIGN AND IMPLEMENTATION 

The client/server design allows a PSDL-server to communicate with a GUI-client. 
The design is successful in decreasing the coupling between the GUI-client and the real- 
time prototype application. The GUI-client can be created with almost any GUI 
development tools. In addition, the design allows the GUI-client to be located on a local 
or remote CPU. The GUI-client can be unbound or bound to the real-time schedule of the 
PSDL server. 

The demonstrations, using a variety of commercial products, show the successful 
implementation of the design. In addition, the proper use of threads and GUI- 
client/PSDL-server communications (synchronous/asynchronous) is very important. If 
implemented properly, the client/server middleware does not effect the performance of the 
prototype. 

Although this thesis did not finish the integration of a new interface editor in 
CAPS, many GUI development tools were evaluated for possible integration. The 
client/server design increases the number of GUI development tools that can be used in the 
CAPS environment. The Java development tools were determined to be the best tools 
available to use with CAPS. The reasons to use Java include: low cost, abundance of 
tools, popularity, language features, and platform independence. 

The largest obstacle for implementation of the design is the client/server 
middleware. For a first implementation, sockets were able to provide the required 
functionality, but the socket programming model is very primitive. Therefore, a higher 
level product must be chosen. CORBA, with Ada, C, C++, and Java interfaces, could be 
used to implement the client/server middleware. 



37 



B. 



FUTURE RESEARCH 



In the course of work on this thesis, many ideas came forward, but were not 
implemented. A great deal of time was spent on the evaluation of GUI tools and 
middleware. The following is a list of ideas for future work. 

1. Selection of Middleware 

In addition to sockets, other middleware should be investigated. CORBA was only 
partially investigated in this thesis, but it could be used to connect atomic operators 
written in Ada to a GUI-client. Other middleware to investigate include: Java’s RMI, 
Microsoft’s DCOM, Netscape’s Caffeine, RPC. 

2. Selection of GUI Development Tools 

A GUI development tool should be selected for full integration into CAPS. In 
addition, a PIGUl would aid in the porting of the other CAPS tools. 

3. Further Demos 

New applications using the new GUI-client/PSDL-server design should be 
demonstrated. Previous CAPS applications could be ported and their performance 
compared. Implementations using a single CPU could be evaluated. 

4. Socket Communications 

If sockets are used, the server-side and the client-side source code could be 
automatically generated. The data structure for passing data between the GUI-client and 
PSDL-server could be standardized. 
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Several protocols exist for socket communications. The socket protocols should be 
compared to find the most efficient method of communications. 

This thesis implemented the PSDL-server by binding the Ada83 code to a C 
module. The C module implemented the socket communication. Ada95 should be able to 
implement a socket connection. 



5. JavaBeans 

A bean is a reusable and interchangeable Java component. Even though JavaBeans 
are a new technology, many vendors are now selling JavaBeans tools. It might be possible 
to create a Java-Bean GUI-client automatically in the CAPS Graphics Editor (GE). 
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APPENDIX A. EVALUATION OF GUI TOOLS 



A. GUI TOOLKITS 



Product Name: 


Java Development Kit 


Vendor: 


Sun Microsystems 
2550 Garcia Ave. 

Mountain View, CA 94043 (800) USA-4SUN 
http://www.javasoft.com 


Type of Tool: 


Language, Library 


PIGGUI: 


Yes 


Supported Platforms: 


Window95/Nt, Macintosh, UNDC 


Cost: 


Free 


Vendor Support: 


Yes 


Future Support: 


Lots of current development 


Languages Supported: 


Java 


GUI builder available: 


No - See third party developers 


Comments: 


Java is an object-orientated, multithreaded, and portable programming 
language. The Abstract Window Toolkit (AWT) is a built-in library for 
creating window components. Java has built-in garbage collection. A 
great deal of work is being on and with Java, but the language is in a 
state of flux. The class library is very comprehensive, but lacks the 
high level GUI object or dialog objects. Many thud parties are 
developing these high level objects. Unfortunately, Java is currently 
slower in execution speed than other languages, but Sun Microsystems 
and other vendors are developing compilers that should bring the 
performance of Java close to other languages. The loading of the Java 
AWT software on a Sun Microsystems Sparcstation ( Solaris 2.5) and 
Windows-95 was very easy. Linking directly with CAPS would be 
difficult. A client/server interface with CAPS was completed in this 
thesis. [Ref. 29] [Rcf.30] [Ref. 36] [Ref. 37] 




Table 1. Java Development Kit 
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Product Name: 


Fresco 


Vendor: 


Fujitsu FASLAB 

800 El Camino, Suite 150 

Menlo Park, CA 94025 (415)325-6015 

http://www.faslabxom 


Type of Tool: 


Toolkit, Similar look-and-feel of Motif 


PIGUI; 


Yes 


Supported Platforms: 


Windows95/NT, UNIX, Linux 


Cost: 


Free 


Vendor Support: 


None, the vendor has completed the research 


Future Support: 


The research on Fresco at FASLAB has be completed. No future work 
seems to be planned. 


Languages Supported: 


C++ 


GUI builder available: 


No 


Comments: 


The Opengroup’s XI 1-V6 (Broadway) contains a sample 
implementation of Fresco. Fresco is user interface system specified 
using CORBA IDL. Even though it is included in the latest version of 
X- Windows, Fresco is not yet a standard. Fresco is a PIGUI, but it 
does not support the native look and feel. Loading Fresco on Sun 
Microsystems Sparcstation (Solaris 2.5) was fairly simple. A tutorial 
walks a new user through examples. Fresco VFX is a fairly complete 
example of what Fresco can do. Fresco has very little low level 
documentation and the software library still seems buggy. There is no 
documentation on how to put the components together into a fmal 
product. Fresco could possibly connect to CAPS via a client/server 
approach. [Ref. 27] 

Table 2. Fresco 


Product Name: 


wx Windows 


Vendor: 


Artificial Intelligence Applications Institute University of Edinburgh 
80 South Bridge 

Edinburgh Scotland Phone: 0131 650 2746 

http://web.ukonline.co.uk/julian.smart/wxwindows.com 


T>pc of l ool 


toolkit library 


IMGUl 


Yes 


Supported Platforms: 


Windows/UNlX( Solaris) 


Cost 


Free 


Vendor Support: 


None 


future Support: 


9 


Languages Supported: 


C++ 


GUI builder available: 


Yes, wxBuilder, Sun Microsystem’s Devguide 


Comments: 


WxWindow is a C++ user interface library. It appears to be one of the 
best toolkits that is free. Loading wxWmdows on a Sun Microsystems 
Sparcstation (Solaris 2.5) was difficult. The GUI builders are not very 
well documented. The class libranes have a lot of features, but learning 
all the classes and methods is difficult. CAPS could interface to 
wxWmdows via a client/server protocol, but linking \\'xWindows into 
CAPS would be very difficult [Ref 13] 




Table 3. WxWindows 
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B. 



GUI BUILDERS 



Product Name: 


UIMX 


Vendor: 


Black & White Software (Resailer) 
2155 S. Bascom Ave., 

Campbell, CA, 95008, 408-369-7400 
http:/www/vedge . com 


Type of Tool: 


GUI-Builder ( Motif) 


PIGUI: 


No 


Supported Platforms: 


UNIX 


Cost: 


-$5000 


Vendor Support: 


yes 


Future Support: 


yes 


Languages Supported; 


C, C++, Ada (add-on product) 


GUI builder available: 


Yes 


Comments: 


UIMX (Figure 19) is a very popular GUI builder. It is resold under 
many different vendors. Integrated products can include: ORBIX for 
client/server, Cross-platform toolset (windows), Ada. [Ref 38] 




Table 4. UIMX 
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Figure 19 UIMX “From Ref. [38]’ 
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Product Name: 


X-Designer 


Vendor: 


Imperial Software Technology 
US Office 

1 20 Hawthorne Avenue Suite 1 0 1 

Palo Alto, California 94301 (415) 688-0200 

http://www.ist.co.uk 


Type of Tool: 


GUI-builder (Motif, Java) 


PIGUI: 


No, Yes for Java 


Supported Platforms: 


UNIX platforms are supported 


Cost: 


-$3000 


Vendor Support: 


Yes 


Future Support: 


Yes 


Languages Supported: 


C, C++, Ada (with XADA), Java 


GUI builder available: 


Yes 


Comments: 


X-Designer (Figure 20) is a Motif development environment. With 
OC-Systems’ XDA, it is possible to convert the output of Visual- 
Workshop to Ada. X-Designer is repackaged in many other 3^^ party 
applications ( Visual Workshop and DataViews ). [Ref 31] 



Table 5. X-Designer 




Figure 20. X-Designer “From Ref. [31]” 
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Product Name: 


Visual Cafe 


Vendor: 


Symantec Corporation 
10201 Torre Ave 

Cupertino, CA 95014 (408) 253-9600 

http :// Symantec .com 


Type of Tool: 


GUI-builder, (Java AWT) 


PIGUI: 


Yes 


Supported Platforms: 


Winows95/NT, Macintosh 


Cost: 


$199 


Vendor Support: 


Yes 


Future Support: 


Yes 


Languages Supported: 


Java 


GUI builder available: 


Yes 


Comments: 


Visual Cafe (Figure 21) is development environment for Java.. 
Loading on Window-95 was very easy. S}miantec has a variety of 
products, including tools to link Java to databases. Linking directly 
with CAPS would be difficult. A client/server interface with CAPS 
was completed in this thesis. [Ref. 34] 



Table 6. Visual Cafe 
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Figure 21. Visual Cafe “From Ref [34]” 



45 





Product Name: 


Builder Xcessory 


Vendor: 


Integrated Computer Solutions 
Cambridge, Mass. (6 1 7) 62 1 -0060 

http://www.ics.com 


Type of Tool: 


Motif and Java Gui Builder 


PIGUI; 


No (Motif), Yes (Java) 


Supported Platforms: 


UNIX: DEC,HP,IBM,SGI,SUN 


Cost: 


$3500 


Vendor Support: 


Yes 


Future Support: 


Seems Good 


Languages Supported: 


Java, C,C++, Ada 


GUI builder available: 


YES 


Comments: 


Builder Xcessory (Figure 22) is a popular GUI builder. Version 4.0 
supports code generation for Motif and Java (applets and applications). 
The tool can be integrated into Pure-Atria’s ClearCase evolution control 
products. There is support for Ada in Version 3. The support for Ada 
is limited to Sun Microsystems platforms and only with the Rational 
and SunAda compilers. [Ref. 39] 



Table 7. Builder Xcessory 



’BmwserP^:^¥^^P^7'W‘^ 









^ \^w Inject Options Managers ^dows 

I ^S«v« ^Cut 



Help 



Tvlfj 



Deleto 







, awttabel 



Er|(awU^p^t ^ g]y^nSader| 



> g)bhjeSlicler| 

awtPanetl — awtCanvas| 






-• .V. v-* 



-I HQ 



3A«w C^iiMO 




m 



Lbl 




9CJUtjBI 



Caiftg 



Oi4d(te» 



glB 



Cho*< 







'tmc 



jo>ftWTi»<winin 






JmAWT Mm«« 


JL t»««J ClMMI 




Syoitvsi OtnBO 





Figure 22. Builder Xcessory “From Ref. [42]’ 



46 









c. 



USER INTERFACE MANAGEMENT SYSTEMS 



Product Name: 


OpenUI 


Vendor: 


Open Software Associates 
20 Trafalgar Square 

Nashua, NH 03063 (800) 44M330 

http://www.osa.com 


Type of Tool: 


UIMS 


PIGUI: 


Yes 


Supported Platforms: 


Wuiows95/NT, UNIX, Linux 


Cost: 


-$4000 


Vendor Support: 


Yes 


Future Support: 


9 


Languages Supported: 


c,c++ 


GUI builder available: 


Yes 


Comments: 


Open Software Associates mam office is m Australia, but there support 
of their product is very good. OpenUI (Figure 23) has built in 
client(GUI)/scrver(LOGlC) application development. A user one must 
learn theu interface language (OPL) to complete a user interface. C, 
C-M- is used to bind to application code. ADA is longer supported. 
OpenUI would be useful for large project. 

[Ref. 15)[Rcf401 



Table 8. OpenlJl 
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Figure 23. OpenUI “From Ref. [43]” 



48 





D. APPLICATION DEVELOPMENT ENVIRONMENTS 



Product Name: 


Visual-Workshop 3.0 


Vendor: 


Sun Microsystems 
2550 Garcia Ave. 

Mountain View, CA 94043 (800) USA-4SUN 

http://www.sun.com 


Type of Tool: 


GUl-builder / Development Environment (Motif) 


PIGUI: 


NO 


Supported Platforms: 


Solaris!, Other UNIX platforms are supported with Imperial Software 
Technology’s X-Designer. 


Cost: 


-$3000 


Vendor Support: 


Yes 


Future Support: 


Sun Microsystems is a leader in this market. 


Languages Supported: 


C, C-H-, Ada (with XADA) 


GUI builder available: 


Yes 


Comments: 


Visual-Workshop (Figure 24) is a Motif development environment that 
includes Imperial Software Technology’s X-Designer (GUI-builder). 
Visual- Workshop is a complete engineering environment with a GUI 
builder, debugging tools, and evolution control tools. Installation of the 
software was very easy. A demonstration version can be downloaded 
and evaluated. The GUI builder is very easy to use. Linking directly 
with CAPS would be difficult, because of the event manager. A 
client/server interface with CAPS was completed in this thesis. With 
OC-Systems' XDA, it is possible to convert the output of Visual- 
Workshop to Ada. 

[Ref 21][Rcf 4l]fRef 42)fRcf 43] 




Table 9. Visual Workshop 
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Figure 24. Visual Workshop “From Ref. [21]” 
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Product Name: 


Galaxy 


Vendor: 


Visix 

1 1440 Commerce Park Dr. 

Reston, Virgina 22091 (800) 832-8668 

http://www.visix.com 


Type of Tool: 


Application Development Environment, GUI-builder 


PIGUl: 


Yes 


Supported Platforms: 


Win/NT, UNIX 


Cost: 


$9600 


Vendor Support: 


Yes 


Future Support: 


Yes 


Languages Supported: 


C, C++ 


GUI builder available: 


Yes 


Comments: 


Galaxy (Figures 25, 26) is complete software engineering environment. 
Galaxy is an emulated API. An emulated API does not require high 
level toolkits to compile the program. For example, when Galaxy 
emulates Motif, Galaxy does not have to link in Motif libraries. A 
benefit of the emulated approach is that you can try out a Macintosh 
look-and-feel on a UNIX workstation. It also has a full range of other 
tools including: image and color editors. [Ref 20] 



Table 10. Galaxy 
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Figure 25. Galaxy (Motif) “From Ref. [20]’ 
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Figure 26. Galaxy (Windows) “From Ref. [20]” 
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E. 



OTHER GUI TOOLS 



Product Name: 


DataViews 


Vendor: 


DataViews Corporation (formerly VI Corp) 

47 Pleasant St., 

Northampton, MA 01006 (413)586-4144 

http://www.dvcorp.com 


Type of Tool: 


Data Visualization for Real-time applications (Motif) 


PIGUI: 


9 


Supported Platforms: 


UNIX- Deployable on (VMS, Window-NT, WindowS.l) 


Cost: 


'-SI 8,000 


Vendor Support: 


yes 


Future Support: 


Languages Supported: 


C, C-H-, Fortran, Pascal 


GUI builder available: 


yes, an enhanced version of X-Designer 


Comments: 


Dataviews (Figure 27) is a data visualization tool for real-time 
applications. [Ref. 19] 



Table 11. Datavews 




Figure 27. DataViews “From Ref. [19]” 
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Product Name: 


Matlab 


Vendor: 


The MathWorks, Inc. 

24 Prime Park Way, 

Natick, Mass, 01760 (508) 653-1415 

http://www.mathwork.com 


Type of Tool: 


Numeric Computation, Graphing, and Visualization 


PIGUI: 


Partially, many programs can be run on different platfonns with no 
change. 


Supported Platforms: 


UNIX, Window95/NT, Macintosh 


Cost: 


Varies on Platfonns and options 


Vendor Support: 


Yes 


Future Support: 


Yes 


Languages Supported: 


Script Language, can be bound to C 


GUI builder available: 


Yes 


Comments: 


Matlab (Figure 28) is a popular signal processing and visualization tool. 
Additional toolboxes can be added Matlab. GUIs can be easily created 
in MATLAB. The Matlab scripting language is easy to use and there 
are many example of source code available. [Ref 18) 



Table 12. Matlab 
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Figure 28. Mallab “From Ref. [18]” 
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APPENDIX B. SOURCE CODE 



A. ROBOT PSDL-SERVER 



Robot PSDI.-server: file rohot.psdl 



TYPE a data 
SPECIFICATION 
END 

IMPLEMENTATION ADA a_data 
END 

TYPE pv_data 
SPECIFICATION 
END 

IMPLEMENTATION ADA pv_data 
END 

TYPE pva_data 
SPECIFICATION 
END 

IMPLEMENTATION ADA pva_data 
END 

OPERATOR bop_calc 
SPECIFICATION 
INPUT 

bnss_pv_data : pv data, 
bnss statc : pva_dala 
OUTPUT 

bnss a data : a_data, 
bnss cTTor ; INTEGER, 
bnss_pva_data : pva_data, 
bnss_ state : pva data 
MAXIMUM EXECUTION TIME 25 MS 
END 

IMPLEMENTATION ADA bop_calc 
END 



OPERATOR bop_display 
SPECIFICATION 
INPUT 

bnss_pva_data ; pva dat 
MAXIMUM EXECUTION TIME 5 MS 
END 

IMPLEMENTATION ADA bop_display 
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Robot PSDL-server: file robot. psdl (cont.) 



END 

OPERATOR boperror 
SPECIFICATION 
INPUT 

bnss_error : INTEGER 
MAXIMUM EXECUTION TIME 5 MS 

END 

IMPLEMENTATION ADA bop_error 

END 

OPERATOR bopflrethrusters 
SPECIFICATION 
INPUT 

bnss_a_data : a_data 
MAXIMUM EXECUTION TIME 5 MS 

END 

IMPLEMENTATION ADA bop_fire_thrusters 

END 

OPERATOR bop_input 
SPECIFICATION 
OUTPUT 

bnss jjv data : pv data 
MAXIMUM EXECUTION TIME 5 MS 

END 

IMPLEMENTATION ADA bop input 



END 



OPERATOR roboJ4 
SPECIFICATION 
END 

IMPLEMENTATION 

GRAPH 

\TRTEX bop_calc ; 25 MS 

VERTEX bop_display : 5 MS 

N'ERTEX bop error ; 5 MS 

\'ERTEX bop_nrc_thrusters ; 5 MS 

VERTEX bop input : 5 MS 

EDGE bnss_a_data 
bop calc -> 
bop_firc_thrustcrs 
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Robot PSDL-server: file robot.psdl (cont.) 



EDGE bnss error 
bop_calc -> 
bop_error 

EDGE bnss_pv_data 
bop input -> 
bopcalc 

EDGE bnss_pva_data 
bop calc -> 
bop_display 

EDGE bnss_state 
bop calc -> 
bop_calc 
DATA STREAM 
bnss_a_data : a data, 
bnss_error : INTEGER, 
bnss_pv_data : pv_data, 
bnss_pva_data : pva_data, 
bnss^state ; pva_data 
CONTROL CONSTRAINTS 
OPERATOR bop_calc 
PERIOD 50 MS 

OPERATOR bop_display 
TRIGGERED BY ALL 
bnssjpvadata 

OPERATOR bop_^crror 
TRIGGERED BY ALL 
bnsscTTor 

OPERATOR bop firc thrusters 
TRIGGERED BY ALL 
bnssadau 

OPERATOR bop input 
PERIOD 200 MS 
END 
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Robot PSDL-server: file ada.h 



/* 



- FILE : ada.h 

- CSCI : Robot Controller 

— Date : June 1996 

— Author : 



*/ 



typedef struct { 

int ix; 

int iy; 

int ir; 

} Rec, *Rec_Ptr; 
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Robot PSDL-server: file global, h 



I* 



- FILE : global.h.a 
“ CSCI : Robot Controller 
“Date : June 1996 
-- Author 

-- Compiler : Sun/Ada 



*/ 



Struct data 


{ 




int 


ix; 


int 


iy; 


int 


ir; 



}; 
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Robot PSDL-server: file hopjdataM 



— FILE : bop_a_data.a 

-- CSCI : Robot Controller 

— Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



with text^io; 
use texMo; 

— defmition for a data stream of robot acceleration values 

package a_data_PKG is 

type a_data is record 

xacc : FLOAT := 0.0; 
yacc : FLOAT := 0.0; 
end record; 

end a_data_PKG; 
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Robot PSDL-server: file hop_calc.a 



— FILE : bop calc.a 

— CSCI : Robot Controller 

— Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



withTEXTJO; 
use TEXTJO; 
with a_data_Pkg; 
with pva_data_Pkg; 
with pv_data_Pkg; 
with math; 
use math; 

— This is the central operator of the robot ’’soft landing process”. 

— On the fu-st call to this operator, initial input is prompted for. 

— On subsequent calls, this operator calculates the robot's distance 

— from the origin and adjusts acceleration as necessary to bring 

— the robot to a soft landing within the required "doughnut”. The 

— algorithm used is to continually adjust thruster acceleration 

— as follows: 

— Calculate the robot's distance from origin. 

— If the robot is too close to the center, 

— issue an error message. 

Else if inside the doughnut, 

set acceleration to force robot to stop in 2 periods. 

— if the robot is moving very, very slow, 

issue a "DONE" message. 

Else, the robot still has a ways to go, so 

calculate thruster acceleration needed to reach origin 
in 2 seconds (the robot may initially speed up, but it 
should eventually experience contmued slowdown as it 

— gels closer to the doughnut relative to it initial 

— distance from the doughnut). 

— If the robot is off the table, 

issue an error message. 

— Calculate the distance moved since the last call to the this 

— operator based on this operator’s calling period. 

Calculate the robot's current velocity. 

Wnte position, acceleration, velocity to outgomg data streams. 
Save the operator's state. 
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Robot PSDL-server: file bop calc.a (cont) 



--Spec 

package bop_calc_Pkg is 

procedure bop_calc(bnss_state: in out pva_data_Pkg.pva_data; bnss_pva_data: out 
pva_data_Pkg.pva_data; bnss_a_data: out a_data_Pkg.a_data; bnss error: out INTEGER ;bnss_pv_data: in 
pv_data_pkg.pv_data); 
end bop_calc_Pkg; 



—Body 

package body bop_calc_Pkg is 

package FL_IO is new TEXT_IO.FLOAT_IO(FLOAT); 

firsttime : INTEGER := 1 ; 

procedure bop_calc(bnss_state: in out pva_data_Pkg.pva data; bnss_pva_data: out 
pva_data_Pkg.pva_data; bnss_a_data: out a_data_Pkg.a_data; bnss error: out INTEGER ;bnss_pv_data: in 
pv_data_Pkg.pv_data) 
is 

dis_from_center : FLOAT; 
xvel_desired: FLOAT; 
yvel^desired: FLOAT; 
tmpf : FLOAT; 



xpos 


: FLOAT := 


ypos 


: FLOAT := 0.0; 


xvel 


: FLOAT := 0.0; 


yvel 


: FLOAT ;= 0.0; 


xacc 


: FLOAT := 0.0; 


yacc 


: FLOAT := 0.0; 


begin 





else — load the previous state to local variables 
xpos := bnss state.xpos; 
ypos bnss^siate.ypos; 
xvel := bnss state.xvel; 

yvel := bnss state.yveL 
xacc :*= bnss_state.xacc; 
yacc := bnss_state.yacc; 
end if; 

if bnss_j)v_data.irequest /= Olhen 
xpos := FLO AT(bnss_pv_data.xpos)/l 000.0; 
ypos := FLOAT(bnss_pv_data.ypos)/ 1000.0; 
end if; 

bnss_error := 0; 
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Robot PSDL’Server: file bop calc, a 



— Calculate Distance from Center 
dis_from_c enter := Sqrt(xpos * xpos + ypos *ypos); 

if dis_from_center < 0.01 then — In to close to center 
PUT_LINE('Too Close”); 
bnss_error := 1 ; 

elsif dis_ffom_center < 0.02 then — Inside circle 
xacc := -xvel * 20.0; ~ Stop in 2 periods 
yacc := -yvel * 20.0; 

if abs(yvel) < 0.00001 then 

if abs(xvel) < 0.00001 then 
PUT(”DONE"); 

end if; 
end if; 

else 

— Adjust acceleration 

xvel_desired := - ( xpos / 2.0); — Reach center in 2s 

yvel_desired := - ( ypos / 2.0); 

xacc := - ( xvel - xvel_desired); 

yacc := - ( yvel - yvel desired); 

end if; 

if abs(xpos) > 1 .0 then — Off the table 
PUT_LINE(”OFF THE TABLE X”); 
bnss_error := 2; 

end if; 

if abs(ypos) > 1 .0 then 

PUT^LINE(”OFF THE TABLE Y”); 
bnss_crror := 3; 

end if; 



•• Calculate Distance Moved 
xpos xpos ^ (xvel • 0.05) + (xacc * 0.00125); 

ypos :* ypos (yvel * 0.05) + (yacc * 0.00125); 
— Calculate New Velocity 

xvel := xvel ^ (xacc • 0.05); 
yvel := yv'el ^ (yacc • 0.05); 

— write to output data streams 
bnss_pva_data.xpos := xpos; 
bnss_pva_data.ypos := ypos; 
bnss_pva_data.xvel := xvel; 
bnss_pva_data.yvcl := yvel; 
bnss_pva_data.xacc := xacc; 
bnss_pva_data.yacc := yacc; 
bnss_a_data.xacc := xacc; 
bnss_a_data.yacc := yacc; 
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Robot PSDL-server: file hopjoalc.a (cont.) 

— save this operators state 
bnss_state.xpos := xpos; 
bnss_state.ypos := ypos; 
bnss_state.xvel := xvel; 
bnss state.yvel := yvel; 
bnss state.xacc := xacc; 
bnss_state.yacc := yacc; 

end bop_calc; 
end bop_calc_Pkg; 
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Robot PSDL-server: file bop_displav.a 



— FILE : bop_display.a 

-- CSCI : Robot Controller 

— Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



with TEXT_IO; 
use TEXT_IO; 
with pva_data_Pkg; 
with sockct_Pkg; 
use sockct_Pkg; 



package bop_display_Pkg is 

procedure bop_display(bnss_pva_data: in pva_data_Pkg.pva_data); 
end bop_display_Pkg; 



package body bop_display_Pkg is 
package FL^IO is new TEXTJO.FLOATJO(FLOAT); 

procedure bop_display(bnssjpva_data: in pva_data_Pkg.pva_data) is 



IX INTEGER; 
fx FLOAT; 
fy; FLOAT; 



begin 

IX 0, 

fx •*= bnss_j>va_data.xpos; 
fy :* bnss^pva data.ypos; 
socket(fx,fy.ix). 

end bop display; 
end bop display Pkg, 
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Robot PSDL-server: file bop_error.a 



— FILE : bop_error.a 

— CSCI : Robot Controller 

— Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



with TEXTJO; 
use TEXTJO; 



— All that this operator does is read an error flag 

— setting from its input data stream and writes 

— and error indication to the display if the error 

— flag is set to indicate error. 



—Spec 

package bop^error Pkg is 

procedure bop_error(bnss_error: in INTEGER); 
end bop_error_Pkg; 



—Body 

package body bop_error_Pkg is 

package INTJO is new TEXTJO.INTEGER JO(INTEGER); 

procedure bop_crror(bnss_erTor: in INTEGER) is 

begin 

if bnss_error > 0 then 
INT lO.PUT(bnss crTor); 
PUT^LINE(”ErTor”); 
end if; 

end bop crror; 
end bop_crror_Pkg; 
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Robot PSDL-server: file bopJirejhrustersM 



— FILE : bop_fire_thrusters.a 

~ CSCI : Robot Controller 

— Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



with TEXTJO; 
use TEXTJO; 
with a_data_Pkg; 

— This is sort of a dummy operator that inputs thruster acceleration 

— adjustments and outputs the received adjustment to the system 

— display. Its intended purpose was to effect a more realistic 

— model by having an operator that actually receives the thruster 

— adjustments from the operator that does the thruster adjustment 

— calculations. 

package bop_fire_thrusters Pkg is 

procedure bop_fire_thrusters(bnss_a_data: in a_data_Pkg.a_data); 
end bop_nre_thrusters_Pkg; 



package body bop_fire_thrusters_Pkg is 
package FL^IO is new TEXT_10,FL0AT_I0(FL0AT); 

procedure bop_nre_thrusters(bnss_a_data: in a_data_Pkg.a_data) is 
ftmp : FLOAT := 0.0; 



begin 



if bnss a data.xacc > 0.0 then 
Putr Left Thruster ="); 

FL IO.PUT(bnss_a_data.xacc,0,3,0); 

Putf* Right Thruster =”); 
FL_IO.PUT(fbnp,0,3,0); 
else 

Put(" Left Thruster ="); 
FL^IO.PUT(ftmp,0,3,0); 

Put(” Right Thruster =”); 

FL IO.PUT(abs(bnss_a_data.xacc),0,3,0); 
end if; 
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Robot PSDL-server: file bop fire thrusters m (cont.) 



if bnss_a_data.yacc > 0.0 then 
Put(" Bott Thruster ="); 
FL_IO.PUT(bnss_a_data.yacc, 0,3,0); 

Put(" Top Thruster =”); 

FL_IO.PUT(ftinp, 0,3,0); 
else 

Put(" Bott Thruster ="); 

FL_IO.PUT(ftnip, 0,3,0); 

Put(" Top Thruster-'); 
FL_IO.PUT(abs(bnss_a_data.yacc),0,3,0); 
end if; 

NEWSLINE; 

end bop_fire_thrusters; 
end bop_fire_thrusters_Pkg; 
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Robot PSDL-server: file hopJire_inputs.a 



— FILE : bop input.a 

— CSCI : Robot Controller 

-Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



with TEXTJO; 
use TEXTJO; 
with socket_Pkg; 
use socket_Pkg; 
with pv_data_Pkg; 

package body bop_input_Pkg is 

procedure bop_input(bnss_pv_data: out pv_data_Pkg.pv_data) is 

ir; INTEGER; 
fx: FLOAT; 
fy: FLOAT; 

begin 

ir ;= 1; 
fx := 0.0; 
fy := 0.0; 

sockct(fx,fy,ir); — Check the GUI for input 

bnss_pv_data.xpos := fx; 
bnss_pv_data.ypos := fy; 
bnss_pv_data.irequest := ir; 

end bop input; 
end bop_input_Pkg; 
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Robot PSDL-server: file bop _pv_data,a 



— FILE : bop_pv_data.a 

— CSCI : Robot Controller 

— Date : June 1997 

— Author : 

— Compiler : Sun/Ada 



with text_io; 
use text_io; 

— defmition for a data stream of robot position, 
~ velocity, and acceleration values 

package pv_data_PKG is 

type pv_data is record 

irequest : INTEGER := 0; 
xpos : FLOAT := 0.0; 
ypos : FLOAT := 0.0; 
xvel : FLOAT := 0.0; 
yvel : FLOAT := 0.0; 
end record; 

end pv data PKG; 
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Robot PSDL-server: file hop _pva_data.a 



— FILE : bop__pva_data.a 

~ CSCI : Robot Controller 

-Date : June 1996 

— Author : 

— Compiler : Sun/Ada 



with text_io; 

use text_io; 

— definition for a data stream of robot position, 

— velocity, and acceleration values 

package pva_data_PKG is 

type pva_data is record 

xpos : FLOAT ;= 0.0; 
ypos : FLOAT := 0.0; 
xvel : FLOAT := 0.0; 
yvel : FLOAT := 0.0; 
xacc : FLOAT := 0.0; 
yacc : FLOAT := 0.0; 

end record; 

end pva data PKG; 
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Robot PSDL-server: file socket. a 



— FILE : socket.a 

— CSCI : Robot Controller 

-Date : June 1996 

— Author : 

— Compiler : Sun/Ada 

—Purpose : The package contains the procedure socket 
—which is used to pass data to GUI-client. 

—Socket binds to the C program that does the 
—actual socket connection. 



with text_io; 
use text_io; 



—Spec 

package socket_PKG is 

procedure socket(xx: in out Float; yy: in out Float; 
ireq: in out INTEGER); 

end socket_PKG; 



-pkg 

package body socket_PKG is 

— to instantiate integer generic 

al : FLOAT; 
bl : FLOAT; 

type Rcc is record 

ix: Integer ; 
ly: Integer ; 
ir: Integer ; 
end record; 

type Rec Ptr is access Rec; 

I : Rec Ptr := new Rec; 

pragma LINK WITH ("server.o”); 
procedure servcr(l : in Rec Ptr); 
pragma Interface (C, server ); 

procedure Socket(xx: in out Float; yy: in out Float; 
ireq: in out INTEGER) is 
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Robot PSDL-server: file socket m (coni.) 



begin 



al := XX * 1000.0; 

I.ix :=INTEGER(al); 
bl := yy * 1000.0; 

Liy := INTEGER(bl); 
I.ir := INTEGER(ireq); 
server(I); 

XX := FLOAT(I.ix); 
yy := FLOAT(I.iy); 
ireq := I.ir; 



end Socket; 



end socket_PKG; 



Robot PSDL-server: file server.c 



/* 



-- FILE : server.c 

— CSCI : Robot Controller 
-Date : June 1997 

— Compiler : gcc 



— This program implements the C socket connection. 
*/ 

#include <stdio.h> 

^include <fcntl.h> 

#include <ermo.h> 

#include <signal.h> 

#include <strings.h> 

#include <sys/types.h> 

#include <sys/socket.h> 

#include <netinet/in.h> 

^include <netdb.h> 

#include <sys/filio.h> 

#include ”confer.h" 

^include "global.h" 

^include ’’parse.h" 

^include ”ada.h” 

^define MAX 128 
^define MAXFILTERS 100 
^define MAXRECORDS 100 

exiem ml ermo; 

void close connectionO; 

stnici sockaddr in My Sockaddr; 
ini isock; 

struci data rccmcssagc; 
stnici data sendmessage; 
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Robot PSDL-server: file server. c (cont.) 



Function server 
Arguments: Rec_Ptr Info; 

Return: None 

Purpose: Sends data to the client. 

The struct defined in message being the structure 
data defined in global.h. Will return 1 if able send. 

server(Info) 

Rec_Ptr Info; 

{ 

int ret; 

sendmessage.ix = Info->ix ; 
sendmessage.iy = Info->iy ; 
sendmessage.ir = Info->ir ; 

ret = inet_server(); 
if(ret < 0) 

printfC'failed to read message socket may have died\n”); 

Info->ix = recmessage.ix; 

Info>iy = recmessage.iy; 

Info->ir = recmessage.ir; 

} 

Function inet_server 
Arguments: None 
Return: integer 

-1 if fails to read or socket died 
Purpose: Sets up server. Will return 1 if able 

to read. Will return -1 if fails or socket has 
died. 



* 

met ser\'er() 

{ 

int result; 

signal(SIGPIPE, close connection); 
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Robot PSDL-server: file server, c (cont.) 

if(isock < 1 ) 

{ 

set_up(); 

} 

ifl[isock < 1) 

{ 

return(-l); 

} 

result = msgs(); 

/• Determine whether we’ve exited because of an error or the 
* connection has been disconnected. 

*/ 

if (result < 0) 

( 

perror("read failed’’); 

isock = 0; 
rctum(-l); 

} 

if( result < 1) /* socket died*/ 

I 

isock = 0; 
reUim(-l); 

I 

rctum(l); 

I 

Function: setup 
Arguments: none 
Return; mt (-1 if fails) 

Purpose; Continues the socket setup. Listens for a connection. 

*****••**•***•*******•**********/ 

int set upO 

( 

static struct sockaddr in from; 
sutic mt length ^ sizeof(from); 
static int firsnime « 1; 

if (firsttime) 

{ 

/• Set-up the connection */ 
iHinit isock connO < 0) 

I 

retum(-l); 

); 

/• Get ready to accept from */ 
iaiisten( LISTENER, 1)<0) { 
perrorC*listen”); 
retum(-l); 

I 

firsttime = 0; 
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Robot PSDL-server: file server. c (cont.) 



/* Accept new data connection */ 
if((isock = accept(LISTENER, &from, &length)) < 0) 
Error_Abort("accept"); 

fprintf(stderr, ”connected\n"); 



Function: msgs 
Arguments: none 
Return: int 

Purpose: Performs the reading and writing on the socket. 

msgs() 

{ 

static int ii = 0; 
int rest; 

struct sockaddr_in from; 

int from_len = sizeof(struct sockaddr in); 

int remnant = 0, cc; 

int itmp,ret,bytes; 

static int count = 1 ; 

char test[100]; 

int icount = 0; 

ret=0; 

writc(isock, &sendmessage, sizeofl[sendmessage)); 
ifKisock > 0) 

cc *= rcad(isock, test, 1 ); /* read check byte */ 

iO;tcst[0] = 1) 

{ 

iHisock > 0) 

cc = rcad(isock, &rccmcssage,sizeofl[recmessage)); /• read data structure */ 

} 

else 

I 

recmessagc.ix = 0; 
rccmessagc.iy = 0; 
recmessagc.u- = 0; 
retum( 1 ); 

1 

rest = 12-cc; 
iHrcst !* 0) 

I 

cc = rccvfrom(isock, test,rest,0,&from,&from_len); 
rest = rest - cc; 

1 

rctum(l); 

} 
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Robot PSDL-server: file server. c (cont.) 



**************************** ******************* 

Function: close_connection 
Arguments: none 
Return: void 

Purpose: Close the socket when a SIGPIPE accurs. 
****************************************************/ 
void close_connection() 

{ 

shutdown(isock, 2); 

fprintf(stderr, "SIGPIPE received... exitingVn"); 

close(isock); 

isock = 0; 



} 

/* 

* Set-up a TCP connection 

*/ 

int init_isock_conn() 

{ 

int sock; 

struct sockaddr in server; 
struct hostent *hp; 
struct servent *sp; 

bzcro((char *)&server, sizeof( server)); 

ifUsock = sockct(AF_INET, SOCK_STREAM, 0)) < 0) 

{ 

Error_Abort("socket"); 

rctum(-l); 

} 

iflsctsockopUsock, SOL_^SOCKET, SO_^REUSEADDR, (char *)0,0) < 0) 
Error_Abort( "sctsockopt, 1"); 

iflsctsockoptlsock, SOL^SOCKET, SO_DONTLINGER, (char *)0,0) < 0) 
ErTor_Abori("sctsockopt,2"); 

/♦ 

iHisp = gctsmbyname( service, "tcp")) = NULL) { 

fprintHstdcn, "isock: tcp/isock service not available\n"); 
cxit(-l); 

I 

scrv cr.sin_port = sp->s_port; 

*/ 

scr\'cr.sinjport = 4141; /• Hard code port number , should use services file */ 

server. sin_family = AFINET; 
server. sin_addr.s_addr = INADDR^ANY; 
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Robot PSDL-server: file server. c fcont. ) 



if(bind(sock, &server, sizeof(server)) < 0) 

{ 

perror("bind"); 

close(sock); 

retum(-l); 

} 

if (sock != LISTENER) { 

if (dup2(sock, LISTENER) = - I) 
fprintlfstdeiT, "\nINIT_CONN: dup2 failed\n"); 



return! 1); 

) 
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B 



ROBOT JAVA GUI-CLIENT 



Robot JAVA GUI-client : file lander.html 



JAVA - Applet GUI-Client 

<html> 

<head> 

<title>CAPS Robot Lander Craft - Client/Server JAVA JDK 
</title> 

</head> 

<body background="ste.jpg" bgcolor=''#FFFFFF"> 

<h2> 

NRAD/NPS MS Software Engineering — 

</h2> 

<p> 

CAPS - Client/Server JAVA - Robot Lander 

<p> 

<APPLET CODE="Lander" WIDTH=400 HEIGHT=500> 
‘C/APPLE'D* 

</HTML> 

</body> 
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Robot JAVA GUI-client: file lander. Java 



+ + + + + + + + + + + + + + + + + + + + + * + + + + * + + + + + + + + * + + 

* File: lander.java 
+ 

* Lander is an applet GUI-client for the robot. Communications with 

* the PSDL-server is via socket communications. The x,y locations are 

* passed from the server. 

* 

♦Date: 8/97 
+ 

:|e9|C9|c:ie:ie9|c:iC3|c9|C9|C%:ic4::iej|C3|C9|C9|C9|C9|C9|C9|C9|C9|C9|C9|C9|C**9|C9|C**************3|C***9»:***9|C3|C9|C 



import java.awt,*; 
import java.applet.*; 
import java.util.*; 
importjava.net.*; 
import java.lang.*; 
import java. io.*; 

public class Lander extends Applet implements Runnable 

{ 

MediaTracker theMediaTracker; 

Image imageDuke,imageBack; 

Image imageBuffer; 

Image buffer; 

Graphics imageBufferG, bufferG; 

Thread tl; 

//RandClient rl; 

int XX, yy; 

int newx,newy; 

double dcompress = 1 .0; 

boolean bNecdToRestart = false; 

boolean bRunnmg = false; 

TcxtFicld xFicld,yFicld; 

TcxtFicld xvField,yvFicld; 

TcxtFicld xaField,yaField; 

Button startButton; 

Button bZoomIn,bZoomOut; 

public void siartO 

{ 

Systcm.out.pnntln(”starl **); 

XX = 0; 
yy = 0; 

} 
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Robot JAVA GUI-client: file lander java (cont,) 



public boolean action(Event evt, Object arg) 

{ 

boolean retVal = false; 

if(evt. target = bZoomln) 

{ 

dcompress = dcompress* 1.2; 

buildbackO; 

repaintO; 

retVal = true; 

} 

if(evt.target = bZoomOut) 

{ 

dcompress = dcompress/1.2; 

buildbackO; 

repaintO; 

retVal = true; 

} 

ifl((evt.target = startButton) 

IKevt.target = xField) 

IKevt.target = yField)) 

{ 

String xvalue,yvalue; 
double x,y; 

if(bRunning = false) 

{ 

bRunning = true; 
tl = new Thread(this); 
tl.startO; 
repaintO; 

} 

xvalue = xField.getTextO; 
yvalue = yField.getText(); 

if((xvalue != null) && (yvalue 1= null) && !xvalue.equals("") &<& 

!y\'aluc.equals(*’")) 



//cvalue = Double.toString(c); 

//cField.setText(cvalue); 

newx = lnteger.parselnt( xvalue); 

newy = Integer.parselnt(yvalue); 

bNeedToRestart = true; 

xx = newx; 

yy = newy; 
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Robot JAVA GUI-client: file lander.iava {cont.) 



repaint(); 

} 

retVal = true; 

} 

return retVal; 



public void update(Graphics g) 

{ 



paint(g); 

} 

public void paint(Graphics g) 

{ 

Rectangle bounds; 
int w,h; 

double dscreenx, dscreeny; 

Color c; 
int i,max; 

bounds = ihis.boundsO; 

dscreenx = (double)xx*dcompress/10 + 200; 
dscreeny = (double)yy’*‘dcompress/10 + 200; 

bufTerG.drawImage(imageBuffer, 0» 0, this); 
w = imageDuke.getWidth(this); 
h = imageDuke.getHeight(this); 

bufTerG.drawImage(imageDuke,(int)dscreenx-w/2,(int)dscreeny-h/2,w,h,lhis); 
g.drawImage(bufTer, 0» 0, this); 



1 

public boolean mouseDrag( Event event, ini screenx, int screeny) 

{ 

ncwx = (int)(( (double)((10 * screenx) - 2000) )/dcompress); 
newy = (int)(( (double)((10 * screeny) - 2000) )/dcompress); 
XX = ncwx; 
yy = new> ; 

bNeedToRestart = true; 

rcpaintO; 

return true; 

I 



public void slopO 

( 

System.oul.prinllnC'stop ”); 
bRunning = false; 
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Robot JAVA GUI-client: file lander. java (cant.) 



public void init() 

{ 

Rectangle bounds; 

Panel toolbar, toolbar2; 

bounds = this.boundsQ; 

System.out.printbi("init ”); 

this. setLayout( new GridLayout( 14,1 )); 
toolbar = new Panel(); 
toolbar2 = new PanelQ; 
xField = new TextField("1000",6); 
yField = new TextField("1000”,6); 
xvField = new TextField(6); 
yvField = new TextField(6); 
xaField = new TextField(6); 
yaField = new TextField(6); 

startButton = new Button( "Restart"); 

toolbar.add(startButton); 

bZoomln = new Button("Zoom In"); 

toolbar . add(bZoomln) ; 

bZoomOut = new Button("Zoom Out"); 

toolbar.add(bZoomOut); 

toolbar.add(new Label("XY",Label. RIGHT)); 

toolbar.add(xField); 

toolbar.add(yField); 

this.add(toolbar); 
toolbar 2 . add( x vF ield) ; 
toolbar2 . add( yvField) ; 

toolbar2.add(new Label("XYacc",Ubel.RIGHT)); 

toolbar2.add(xaField); 

loolbar2.add(yaField); 

this.add(toolbar2); 

//"dukes.gif’); 

//”photo__7.gir); 

imageDuke = getlmage(getDocumentBase(), "dukes. gif’); 
// ent.gif 

//imageBack = gellmage(getDocumentBase(), "sal.gif’); 

loolbar2.add(new Label(”XYver\Label.RIGHT)); 
imageBufTer = crealelmage(si 2 e(). width, size(). height); 
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Robot JAVA GUI-client: file lander. java (cont.) 



imageBufferG = imageBuffer.getGraphics(); 

buffer = createlmage(size().width, size().height); 
bufferG = buffer.getGraphics(); 



theMediaTracker = new MediaTracker(this); 
//theMediaTracker.addImage(imageBack,0); 
theMediaTracker.addImage(imageDuke, 1 ); 
try 
{ 

theMediaTracker.waitForAll(2000); 

} 

catch(InterruptedException ex) { } 
buildback(); 



public void buildback() 

{ 

double dx,dtmp,dtmp2; 

Rectangle bounds; 
int w,h,ii; 

bounds = this.boundsO; 

//System.out.println(”build ”+bounds.width); 

//imageBufferG.clearRect(0,0,bounds.width,bounds.height); 

imageBufferG.setColor(Color.black); 

imageBufTerG.fillRect(0,0,bounds.width,bounds.height); 

//w = imageBack.getWidth(this); 

//h = imageBack,getHeight(this); 

//imagcBuflcrG.drawImage(imageBack,200-(int)((double)w*dcompress)/(2*4),200- 

(intH(doublc)h^dcomprcss)/(2*4),(intX(double)w*dcompress/4,0),(int)((double)h*dcompress/4.0),this); 

dtmp » dcomprcss • 100.0; 
diinp2 = dcomprcss * 200.0; 
imageBufferG. sctColor(Color.ycllow); 

imagcBufTcrG.drawOval(200-(int)dtmp,200-(int)dtmp,(int)dtmp2,(int)dtmp2); 
dtmp = dcomprcss • 2,0; 
dtmp2 = dcomprcss * 4.0; 
imageBufferG. sctColor(Color.blue); 

imagcBuffcrG.drawOval(200-(int)dtmp,200-(int)dtmp»(int)dtmp2,(int)dtmp2); 
dtmp = dcomprcss * 1 .0; 
dtmp2 = dcomprcss * 2.0; 
imagcBuffcrG.setColorfColor.cyan); 

imageBufferG.drawOval(200-(int)dtmp,200-(inl)dtmpXmt)dtmp2,(inl)dimp2); 
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Robot JA VA GUI-client: file lander, java (cont.) 



imageBufferG.setColor(Color.gray); 
imageBufferG.drawLine(200, 0,200, 400); 
imageBufferG.drawLine(0,200,400,200); 

dx = 0.0; 
ii = 0; 

while(dx < 200.0) 

{ 

dx = (double)ii * dcompress; 

imageBufferG.drawLine(200 + (int)dx, 196,200 + (int)dx,204); 
imageBufferG.drawLine(200 - (int)dx, 196,200 - (int)dx,204); 
imageBufferG.drawLme( 196,200 + (int)dx,204,200 + (int)dx); 
imageBufferG.drawLme( 196,200 - (int)dx,204,200 - (int)dx); 
if(dcompress < 2.0) 
ii = ii+ 10; 
else 

ii = ii+ 1; 



public void destroyO 

i 

Sysiem.out.prinlln("desiroy ’’); 

! 

public void run() 

{ 

Socket server; 

InputStream in; 

OutputStream out; 
DatalnputStream dataln; 
DataOutputStream dataOui; 
int ii = 1; 
int iin; 

try 

{ 

tl.slecp(1000); 

} 

caich(lniemipiedException ex) { } 



while(bRunning) 



try 



//server = new Socket(InetAddress.getLocalHost(),4141); 
server = new Socket(”pegasi.nosc.mir\4141); 
in = server.gellnputStreamO; 
out = server.geiOutputStreamO; 
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Robot JAVA GUI-client: file lander. Java (cont.) 



datain = new DatalnputStream(in); 
dataOut - new DataOutputStream(out); 

while(bRunning) 

{ 

iin = dataln.readlntO; 

//System.out.printlnC’The current number is: ’’+iin); 

XX = iin; 

iin = dataln.readlntO; 

//System.out.println(’’The current number is: ”+iin); 
yy = iin; 

iin = dataln.readlntO; 

//System.out.println(”The current number is: ”+iin); 
if(iin = 1) 

{ 

if(bNeedToRestart) 

{ 

dataOut. writeByte( 1 ) ; 
dataOut.writelnt(newx); 
dataOut. writelnt(newy); 
dataOut. writelnt( 1 ) ; 

//System.out.println("The x: ”+newx); 
//System.out.println(”The y: ’’+newy); 
bNeedToRestart “ false; 

} 

else 

{ 

dataOut. writeByte(65); 

) 

} 

else 

{ 

dataOut.writeByte(65); 

repaintO; 

> 

ii = ii+ 1; 

} 

System.out.println( "Closing socket"); 

dataln.closeO; 

in.close(); 

dataOut.closeO; 

out.closeO; 

} 

catch(IOException ex) 

{ 

// System.out.println( "Error connecting to random server") 

} 

} 
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Robot JAVA GUI-client: file lander.iava ('cont.) 



public boolean imageUpdate(Image img, int flags, int x, int y, int w, int h) 

{ 

if(img != imageDuke) 

{ 

buildbackO; 
repaintO; 
return true; 

} 

repaintO; 
return true; 

} 

} 
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c. 



ROBOT VISUAL WORKSHOP (MOTIF) GUI-CLIENT 



Robot Visual Workshop (Motif) GUI-client: file: Makfilp. 



SHELL=/bm/sh 

UILFLA GS=-I/usr/include/uil 

MRMLroS=-lMim 

# Solaris 2.x 

XINCLUDES—I/usr/dt/include -I/usr/openwin/include -I/usr/openwin/include/Xl 1 
XLIBS=-L/usr/dt/lib -L/usr/openwin/lib -R/usr/dt/lib -R/usr/openwin/lib 
LDLIBS=-lgen -Ithread -Isocket -Insl -Im 
CCC=CC 

MRMLIBS=-L/usr/dt/lib -IMrm 
UILFLAGS=-I/usr/include/uil -I/usr/dt/include/uil 
VISUROOT=/opt/SUNWsproAVS4.0 

XPMLIBDIR = ${VISUROOT}/user_widgets/obj 
XPMDIR = $ { VISUROOT}/contrib/xpm/lib 
LDFLAGS = ${XLIBS} -L$ {XPMLIBDIR} 

MOTIFLIBS = -IXpm -IXm -IXt -1X1 1 

XPCLASS = $(VISUROOT)/src/xdclass 
XPCLASSLIBS = $(XPCLASS)/lib/libxdclass.a 

CFLAGS=-I. ${XINCLUDES} -I${XPMDIR} 

CCFLAGS=${CFLAGS} -I${XPCLASS}/h 

UlL=uil 

#DO NOT EDIT »> 

XD_C_PROGRAMS=\ 

bp 

#«< DO NOT EDIT 

#DO NOT EDIT »> 

XD_C_PROGRAM_OBJECTS=\ 

bp.o 

tt<« DO NOT EDIT 

ttDO NOT EDIT »> 

XD_C_PROGRAM_SOURCES=\ 

bp.c 

««< DO NOT EDIT 

ttDO NOT EDIT »> 

XD_C_STUB_OBJECTS=\ 

bpstubs.o 
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Robot Visual Workshop (Motif) GUI-client: file: Makefile (cont.) 



#«< DO NOT EDIT 

#DO NOT EDIT »> 

XD_C_STUB_SOURCES=\ 

bpstubs.c 

#«< DO NOT EDIT 

XD_ALL_C_SOURCES=$(XD_C_PROGRAM_SOURCES) $(XD_C_SOURCES) 
$(XD_C_STUB_SOURCES) $(XD_C_FOR_UIL_PROGRAM_SOURCES) 
$(XD_C_FOR_UIL_SOURCES) 

XD_ALL_CC_SOURCES=$(XD_CC_PROGRAM_SOURCES)$(XD_CC_SOURCES) 

$(XD_CC_STUB_SOURCES) 

all: CHECKENV CHECKROOT $(XD_C_PROGRAMS) $(XD_CC_PROGRAMS) 
$(XD_C_FOR_UIL_PROGRAMS) $(XD_UIL_OBJECTS) 



depend; 

makedepend - $(CFLAGS) $(CPPFLAGS) - $(XD_ALL_C_SOURCES) 
makedepend -a - $(CCFLAGS) $(CPPFLAGS) - $(XD_ALL_CC_SOURCES) 



clean; 

rm -f $(XD_C_PROGRAMS) $(XD_C_PROGRAM_OBJECTS) $(XD_C_OBJECTS) \ 
$(XD_CC_PROGRAMS) $(XD_CC_PROGRAM_OBJECTS) $(XD_CC_OBJECTS) \ 
$(XD_C_STUB_OBJECTS) \ 

$(XD_CC_STUB_OBJECTS) \ 

S(XD_C_FOR_UIL_PROGRAMS) $(XD_C_FOR_UIL_PROGRAM_OBJECTS) 
$(XD_C_FOR_UIL_OBJECTS) \ 

S(XD_UIL_OBJECTS) 

CHECKENV': 

(alcst -n "S(VISUROOT)" || (echo You must set \$$VlSUROOT in the makefile or in your shell 
environment; exit 1 ) 

CHECKROOT: 

(inest -d "S(XPCLASS)" |1 (echo \$$VISUROOT must point to a valid root directory; exit 1) 
^lest -d "S(VlSUROOT)/make_templates’' || (echo \$$VlSUROOT must point to a valid root 
directoiy; exit 1 ) 

#DO NOT EDIT »> 

bp; client. o th 1.0 lander.o bp.o S(XD_C_OBJECTS) $(XD_C_STUB_OBJECTS) 

S(CC) -g S(CFLAGS) S(CPPFLAGS) $(LDFLAGS) -o bp client.o thl.o lander.o bp.o 
$(XD_C_OBJECrS) S(XD_C_STUB_OBJECTS) $(M0TIFL1BS) $(LDL1BS) 

#«< DO NOT EDIT 

#D0 NOT EDIT »> 
bp.o; bp.c 

$(CC) -g $(CFLAGS) $(CPPFLAGS) -c bp.c 
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Robot Visual Workshop (Motif) GUI-client: file: Makefile (^cont.) 



#«< DO NOT EDIT 

#DO NOT EDIT »> 
bp_stubs.o: bp_stubs.c 

$(CC) -g $(CFLAGS) $(CPPFLAGS) -c bp_stubs.c 
#«< DO NOT EDIT 
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Robot Visual Workshop (Motif) GUI-client: file: bp stubs, c 



/* 

** Generated by Workshop Visual 
*/ 

/* 

** Workshop Visual-generated prelude. 

** Do not edit lines before "End of Workshop Visual generated prelude" 
** Lines beginning ** Workshop Visual Stub indicate a stub 
** which will not be output on re-generation 
*/ 

/* 

♦♦LIBS: -DCm -DCt-lXll 
♦/ 

#include <X1 l/Xatom.h> 

#include <X1 1/Intrinsic.h> 

^include <X1 1/Shell.h> 

#include <Xm/Xm.h> 

#mclude <Xm/DrawingA.h> 

#include <Xm/PushB.h> 

#include "bp.h" 



extern void XDmanage_link ( Widget w, XlPoinler client data, XlPoinler call_data ); 
extern void XDunmanage_link ( Widget w, XlPointer clienl_dala, XlPoinler call_data ); 
extern void XDpopup_link ( Widget w, XtPomler clienl_data, XlPointer call_data ); 
extern void XDpopdown link ( Widget w, XlPoinler client data, XlPointer call_data ); 
extern void XDmap_link ( Widget w, XlPointer client_data, XlPointer call_data ); 
extern void XDimmap_link ( Widget w, XlPointer clienl data, XlPointer call_data ); 
extern void XDenable_link ( Widget w, XlPointer client data, XlPoinler call_data ); 
extern void XDdisable link ( Widget w, XlPomter clicnt data, XlPointer call data ); 

/♦ End of Workshop Visual generated prelude */ 



/• 

Workshop Visual Stub mybrucecallback 

•/ 

void mybrucecallback(Widgct w, XlPointer client^data, XlPointer xt_call_daia) 

I 

static int fu^ttimc = 1; 

XmPushButtonCallbackStruct *call_data = (XmPushButtonCallbackStruct •) xt_call_dala 



94 



Robot Visual Workshop (Motij) GUI-client: file: bp_stuhs.c fcont.) 



printf(”Bl\n”); 



{ 

oldmainO; 
firsttime = 0; 

} 

send_data( 1 000, 1 000); 



•• Workshop Visual Stub bruce_drawing_callback_resize 
V 



void bruce_drawing_callback_resize( Widget w, XtPointer client_data, XtPointer xt_call_data) 

{ 

GC gc; 

static int firsttime = 1 ; 

XmDrawingAreaCallbackStnict *call_data = (XmDrawingAreaCallbackStruct *) xt_call_data ; 
prinrfI"B2\n”); 

if];! firsttime) 

{ 

sctup_image(w); 

drawbackO; 

} 

firsttime = 0; 



•• Workshop Visual Stub bruce_drawmg_callback_input 

•/ 

void brucc drawing_callback_inpul( Widget w, XtPointer client data, XtPointer xt call data) 

( 

GC gc; 

XtriDrauingAreaCallbackStruct •cal!_data = (XmDrawingAreaCallbackStruct •) xt_call_data ; 
pnntf];’*B3\n"); 

1 
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Robot Visual Workshop ("Motif) GUI-client: file: bp.res 



! Generated by Workshop Visual 



! bp_shell 
! messageBoxl 
! bruce_button 

XApplication*bruce_button.labelString: Restart 
! bruce_drawing 

XApplication*bruce_drawing.foreground: SlateGrey 
XApplication*bruce_drawing.background: GhostWhite 
XApplication*bruce_drawmg.marginWidth: 400 
XApplication*bruce_drawmg.marginHeight: 400 

! cascade 1 

XApplication*cascadel. labelstring: File 
! button 1 

XApplication^buttonl. labelstring: Open 
! button4 

XApplication’^button4. labelstring: Exit 
! cascade2 

XApplication’*cascade2, labelstring: Edit 
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module 'XApplication' 
version = 43; 

applicationName = ’XApplication’; 
generateNameC = * ’bp.c'; 
generateNameCMainProgram = * 'bp.c'; 
generateNameStubs = * *bp_stubs.c’; 
generateNameExtems = * ’bp.h'; 
generateNameResDB = * 'bp.res'; 
generateNameCPixmaps = * 'bp__pixmaps.h'; 
generateCHeaderFile = 'bp.h'; 
generateNameMakefile = 'Makefile'; 
generateMask =12; 
useMask = 1 ; 
ansiC = 1 ; 

generateNewMakefile = 1 ; 
generateMakeTemplate = 0; 
useCPixmaps = 0; 
useUILPixmaps = 0; 
useCHeaders = 1; 
useCUILHeaders = 0; 

CPPFlavour = 0; 
useCPPHeaders = 0; 
useCPPHeadersMFCWindows = 0; 
useCPPHeadersMFCMotif = 0; 
object 'bp_sheir : XmDialogShell { 
arguments { 

lastGenName = 'bp_shell'; 
createPreludeStatus = 2; 

prcinstantiation = 'void create_bp_shell (Display ^display, char •app^name, int app_argc, char 
•*app_argv) 

I. 

XmNallowShellResize = true; 

XmNprimary = 1 ; 

); 

object T : XmMcssagcTcmplatc { 
arguments { 

lastGenName = 'mcssagcBoxT; 

XmNautoUnmanage = false; 

XmNdialogType = 0; 

); 

object ’r : XmSeparator GADGET { 
arguments { 
name = 'Separator*; 
lastGenName = 'separator!'; 

}; 



object *brucc_button' : XmPushButton { 
arguments { 

lastGenName = T^rucc^button'; 
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XmNlabel String = ’Restart’; 

}; 

callbacks { 

XmNactivateCallback = ' 
mybrucecallback( ) 



}; 

}; 

object '2* : XmPushButton { 
arguments { 

lastGenName = ’button2’; 

}; 



object '3* : XmPushButton { 
arguments { 

lastGenName = ’buttons'; 

}; 

}; 

object 'bruce_drawing' : XmDrawingArea { 
arguments { 
was_selected = true; 
lastGenName = ’bruce_drawing'; 
generateResName = true; 

XmN foreground = * color('SlateGrey'); 
XmNbackground = * color('GhostWhite'); 
XmNmarginWidth = * 400; 
XmNmarginHeight = 400; 

>; 

callbacks { 

XmNinputCallback = ' 
bruce_drawmg_callback_input( ) 

XmNresizeCallback = ’ 
bruce_drawmg_callback_resize( ) 

I. 

); 

I: 

object T : XmMenuBar { 
arguments { 

lastGenName = 'menuBarl'; 

}; 

object T : XmCascadeButton { 
arguments { 

lastGenName = 'cascade T; 
XmNlabelString = 'File'; 

>; 

object : XmPulldownMenu { 
arguments { 

lastGenName = 'menul'; 

}; 
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object T : XmPushButton { 
arguments { 

lastGenName = ’button 1’; 
XmNIabelString = ’Open’; 
}; 

}; 

object ’4' : XmPushButton { 
arguments { 

lastGenName = ’button4’; 
XmNIabelString = ’Exit'; 

}; 

}; 

}; 

}; 

object '2' : XmCascadeButton { 
arguments { 

lastGenName = ’cascade2'; 
XmNIabelString = ’Edit’; 

}; 

object '2' ; XmPulldownMenu { 
arguments { 

lastGenName = 'menu2'; 

}; 

}; 

}; 

}; 

}; 

}; 

end module; 
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* File: client.c 

Client. c is used to start the socket connection for the GUI-client. It 
communicates with the server. If communication is disrupted, 
it is re-started. Data is sent and received. Communication is hard coded to 
a predefined port number. The server name is also hard- wired. 

This is just a prototype implementation. A better method for 
doing for synchronizing the passing of data should be established. 

* 

• OC-^ version 

• Date: 8/97 

• Compiler: gcc or Sun Compiler 



^include <stdio.h> 
^include <fcntl.h> 
^include <sys/ioctl.h> 
^/include <sys/typcs.h> 
^include <sys/socket.h> 
^/include <nclincl/in.h> 
^include <nctdb.h> 
^include <ciTno.h> 
^include <signal.h> 
^include ’’global.h'* 

int inct(); 
void catchkillO; 
int int client; 
extern int ermo; 



FILE Tsock, 
int gix.giy; 

int gbNeedToStan = 0; 



struct data scndmcssagc; 
struct data rccmcssage; 



/' 



Function: send_data 

Arguments: int x, new x location for robot 
mt y, new y location for robot 
Return: none 

Purpose: Used to request new x,y locations for robot. 





void send_data(int x, int y) 
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gbNeedToStart = 1; 
gix = x; 

giy = y; 



Function client_main 
Arguments: int *x, int *y; 

Return: none 

Purpose: Make connection to server, and it will return 
ix and iy if data is sent from the server. 

void client_main(int *ix, int *iy) 

{ 

int ii; 
int ret; 



ret = sock_data("pegasi.nosc.mir); 
ifl[ret < 0) 

printf( "could not write to socket\n"); 

•ix = (float)recmessage.ix; 

•iy = (float)recmessage.iy; 



Function sock data 

Arguments: char trafTic^host (name of host to connect to) 

Retirni: int ( - I if fails ) 

Purpose: Starts the socket connection, functions 
called:(operu inet_c!ient, inet) 

*•••**•••••**•♦**•*•***/ 

sock_data( traffic host 1 ) 
void char •traffic hostl; 

! 

static int retl =0; 

suuc int sockl; /• inet socket file descriptor */ 

sutic char unix_read[READ_SIZE]; /• array used to read message •/ 

sutic char oldj 5 arsel[READ_SIZE]; /• array to hold partial message •/ 

sgnal(SlGPlPE,catchkill); 

while(retl = 0) 

{ 

sockl = inet_client(traffic_hostl); 
fsock = fdopen(sockl,”w"); 
if[sockl) 
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if(retl) 

retl = inet(sockl); /* inet socket */ 
if(retl = 0) 
retum(-l); 
else 

retum(l); 



y* ***************************************** 

Function inet_client 

Arguments: char traffic_host (name of server to connect to 
Return: int 

Purpose: Continues setup of socket. 



inet_client(traffic_host) 

char *traffic_host; 

{ 

struct sockaddr_in myserver, from; 

int length = sizeof(from); 

struct hostent *hp; 

struct servent *sp; 

int pid; 

int ret; 

mt sock; 

S!gnal(SIGPIPE,catchkill); 

ih[(sock = socket(AF_INET, SOCK^STREAM, 0)) < 0) { 
perror(**could not make socketXn**); 
exit(-l); 

} 



if((hp = gcthostbyname(trafiic_host)) = NULL) { 
pcrror( traffichost); 
cxit(.l); 

} 

myserver. sm_jK)rt = 4141 ; /• Hard coded, should open services files */ 
bcopy(hp->h_addr, &myscrver.sin_addr.s_addr, hp->h_length); 
myserv'cr.smfamily = AFINET; 

iHirct *= connect(sock, &myservcr. sizeoRmyservcr))) >= 0) { 
pnntfV*could make connection \n"); 
rctum(sock); 

} 

pnntfI"could NOT make connection \n”); 

slccp( 1 ); 

closc(sock); 

retum(O); 
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} 



Function inet 

Arguments: int sock (sock file descriptor) 

Return: int 

Purpose: Reads AVrites on socket 
**♦*♦♦*♦♦**** ♦******************♦*♦***♦♦***/ 
inet(sock) 
int sock; 

{ 

int ret; 
int bytes; 

char strg[100]; 

printf(”before Read\n"); 
read(sock,&recmessage,sizeof(recmessage)); 
printf("After Read\n"); 
if(recmessage.ir = 1) 

{ 

ifl(gbNeedToStart) 

{ 

sendmessage.ir = 1; 
sendmessage.ix = gix; 
scndmessage.iy = giy; 
strg(0]-l; 



{ 

sendmessage.ir = 0; 
sendmessage.ix = 0; 
sendmessage.iy = 0; 
strg(O) = 65; 

I 



{ 

sendmessage.u * 0; 
sendmessage.ix = 0; 
sendmessage.iy “ 0; 
strg(O) = 65; 

I 

iHsock > 0) 

ifl[ren=^wnte(sock, strg. 1)<0) 

{ 

perror( "error in write to sock”); 
close(sock); 

retum(O); /• socket write failed return 0 */ 

} 

ifl[sock > 0) 
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if(recmessage.ir = 1) 
if(gbNeedToStart) 

{ 

gbNeedToStart = 0; 

if(ret=write(sock, &sendmessage, sizeof(sendmessage))<0) 

{ 

perror("error in write to sock”); 
close(sock); 

retum(O); /* socket write failed return 0 */ 

} 

} 

printf( "After write\n”); 
fflush(fsock); 

retum(l); /* socket write worked return 1 */ 



Function: catchkill 
Arguments: none 
Return: void 

Purpose:. Catches unix signals, 
void catchkillO 

printf("WE caught a signal\n"); 

} 
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* File: global.h 

* 

* Contains the structure that is used for passing data 

on the socket for the GUI-client. This structure is modified 
for each application. 

* 

* 

* C/C-H- version 

* 

*Date: 8/97 

struct data 

{ 

int ix; 
int iy; 
int ir; 

}; 
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* File: lander.c 

* 

* lander.c does simple X-window drawing for the Visual Workshop (Motif) 

* GUI-client. 

* 

* C/C-H- version 

♦ 

♦Date: 8/97 

#include <X1 l/Xatom.h> 

#include <X 11 /Intrinsic. h> 

#include <X1 1/Shell.h> 

#include <Xm/Xm.h> 

#include <Xm/DrawingA.h> 

#mclude <Xm/PushB.h> 

#include "bp.h” 

Wuidow gwindow; 

Display *gdisplay = NULL; 

Function : drawline 

Arguments: int x, int y, int x2, int y2 

Return: void 

Purpose;. Draws a line from x,y to x2,y2 in the graphics window, 
void drawlme(int x,int y,int x2,int y2) 

I 

GC gc; 

Display •display; 

Window xid; 
int ii; 

xid * gwmdow; 
display ■= gdisplay; 

gc = DefaultGC(display,DefaultScreen(display)); 
XDrawLine(display,xid,gc,x,y,x2,y2); 

} 
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y*9tC***«***9|C***3|C******3|C*****************3|C ************* 

Function : drawcircle 
Arguments: int x, y location of circle 
int width 
int height 
Return: void 

Puipose:. Draw a circle a x,y with width and height. 

«3tc**** **************** ***3|c9|c:|c:|c9|c:|c:|c3|c9(c3|c*********9|c**3|c**3iC3icy 

void drawcircle(int x,int y,int width,int height) 

{ 

GC gc; 

Display ^display; 

Window xid; 
int ii; 

xid = gwindow; 
display = gdisplay; 

gc = DefaultGC(display,DefaultScreen(display)); 

XDrawArc(display,xid,gc,x,y, width, height,0,64*360); 



} 

Function : sctup image 
Arguments: Wiget w 
Return: void 

Purpose:. Gets display attributes from a widget. 

void _image( Widget w) 

{ 

gdisplay = XtDisplay(w); 
gwindow «= XtWindow(w); 

I 



Function : do_ image 
Arguments: int x,y 
Return: int (<0 if error) 

Purpose: Draw the robot at x,y 

••••••••••••••••••••••••••♦•*♦♦*•****•••*♦*/ 

void do_image(int x,int y) 

{ 

static int oldx = 0; 
static int oldy = 0; 

iHx = 0) 

retum(O); 
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if(gdisplay = NULL) 
retum(-l); 

X = x/5 + 200; 
y = y/5 + 200; 
drawbackO; 

clearrect(oldx-l 1, oldy-11, 22, 22); 

drawlander(x,y); 

drawbackO; 

oldx = x; 
oldy = y; 

} 

Function : clearrect 
Arguments: int x,y, width, height 
Return: void 

Purpose: Clears the default display window at position x,y, width, 
height. 

void clearrect(int x, int y, int w, int h) 

{ 

Window xid; 

Display ^display; 



xid = gwindow; 
display = gdisplay; 
XClearArea(display,xid,x,y,w,h,0); 

} 

Function : clear 
Arguments: none 
Return: void 
Purpose:. 

void clearO 

{ 

Window xid; 

Display ^display; 

xid = gwindow; 

display = gdisplay; 

XClearWmdow(display,xid); 
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Function draw_lander 
Arguments: intx,y 
Return: void 

Purpose:. Draw the actual lander. 

void drawlander(int x, int y) 

{ 

drawcircle(x-5,y-5, 10,10); 

drawline(x,y-8,x,y+8); 

drawline(x-8,y,x+8,y); 

} 



^9|Mtc9|e:(c9tt9ic9te9|t9(t9(t9tc9te9|e*9te*9f()|oi(]ie]|e:|ciK3f(:te*9<t*iic«iic***«**i|c*3it**i|c*iic)fc*9<t9<(^9ic9fc 

Function : drawback 
Arguments: none 
Return: void 

Purpose: Draw the screen background. 

void drawbackO 

{ 

drawcircle(0, 0,400, 400); 
drawcircle( 1 96, 1 96,8,8); 
dra wcircle( 1 98, 1 98,4,4); 



} 
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* File: thl.c 

* 

* thl.c is used to create a thread of execution to read 

* on the socket, and register repaint events, for the GUI-client. 

* 

* C/C-H- version 

* 

♦Date: 8/97 

ic*****«*^ *************** *****;(c***:4c**** ******** *«*******« * 

#include <stdio.h> 

#include <math.h> 

#include <thread.h> 

#include <synch.h> 

#include <ermo.h> 

thread_t twriter; 

int X = 0; 
int y = 0; 



^* ******************************* ******************** 



Function: add 
Arguments: none 
Return: none 

Purpose: Add is called by the second. Add never returns. Add is 

in an infinite loop that calls the socket function (client_main) 
to get data from the PSDL-server. 

The Ullage is then drawn. 

****************************/ 



void add() 

{ 

while( 1 ) 

{ 

clicnt_main(&x,&y); 

do_unagc(x,y); 




void sub() 

{ 



\ 



fpnntnstdcrr,**Sub\n"); 



Robot Visual Workshop tMotif) GUI-client: file: thl.c (cont.) 



Function : oldmain 
Arguments: none 
Return: void 

Purpose: Starts the second thread. Add will be called by the 
second thread. 

void oldmainO 

{ 

int i; 

thr_setconcurrency(2); 

thr_create(NULL,NULL,(VPTR)add,NULL,THR_NEW_LWP,&twriter); 

I 
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